chap 6: Qualitaetssicherung und Auslieferung; PR-Uebersichtstabelle

chapters/qa/acceptance-testing.tex

@@ -1,5 +1,40 @@
 \section{Abnahmetest}
 \label{sec:acceptance-testing}
 
-% TODO: Maria-Lena Andersz — Sichtbarkeitsproblem des Menüpunkts (2026-08-13)
-% Rollenzuweisung klären, Bug 10134 (Suchfunktion), finale Abnahme 2026-08-24/25
+\subsection{Ablauf}
+
+Die fachliche Abnahme übernahm \emph{Maria-Lena Andersz}. Sie begann am 13.~August 2026, also zu einem Zeitpunkt, an dem erst ein Teil der Pull Requests zusammengeführt war, und zog sich mit Unterbrechungen bis zum 25.~August. Geprüft wurde gegen die Akzeptanzkriterien der einzelnen Backlog Items auf der Testumgebung.
+
+Die Abnahme zerfiel faktisch in zwei Abschnitte. Der erste war von Zugriffs- und Konfigurationsproblemen geprägt und förderte kaum fachliche Erkenntnisse zutage. Erst nachdem diese behoben waren, konnte die eigentliche funktionale Prüfung stattfinden.
+
+\subsection{Der Menüpunkt war nicht sichtbar}
+
+Der erste Befund lautete, dass der neue Menüpunkt „Dokumente" nicht erscheine. Für eine Funktion, die zu diesem Zeitpunkt bereits mehrere zusammengeführte Pull Requests umfasste, ist das ein ernüchternder Einstieg.
+
+Die Ursache lag nicht im Code, sondern in der Berechtigungsvergabe: Der Testerin war die Anwendungsrolle nicht zugewiesen. Das Verhalten war damit exakt das spezifizierte — ohne die Rolle ist der Menüpunkt unsichtbar (siehe Abschnitt~\ref{sec:authorization}). Die Funktion verhielt sich also korrekt und war dennoch unbenutzbar.
+
+Der Vorgang legt eine Lücke im Vorgehen offen. Die Rolle war Ende Juli für die Entwicklungsumgebung beantragt worden; dass ihre Vergabe an die Testenden ein eigener, ausdrücklich zu veranlassender Schritt ist, war weder in den Akzeptanzkriterien noch in einer Übergabe festgehalten. Eine rollenbasierte Funktion bringt damit eine Anforderung mit sich, die über den Code hinausgeht: Wer testen soll, braucht die Rolle, und wer die Funktion ausrollt, muss dies veranlassen.
+
+An dieser Stelle bewährte sich die in Abschnitt~\ref{sec:authorization} beschriebene Entscheidung für eine 403-Antwort. Hätte die Anwendung stattdessen mit 404 geantwortet, wäre für die Testerin nicht unterscheidbar gewesen, ob die Seite nicht existiert, noch nicht ausgerollt ist oder ihr lediglich die Berechtigung fehlt. Die Fehlersuche wäre entsprechend länger gelaufen.
+
+\subsection{Konfiguration und Testdaten}
+
+Nach der Klärung der Berechtigung folgte ein zweiter Befund: Es wurden keine Dokumente angezeigt. Auch hier lag die Ursache in der Umgebung. Zum einen mussten überhaupt erst Testdateien in den für die Testumgebung vorgesehenen Speicher geladen werden — ein leerer Speicher führt zum leeren Zustand, der wie beabsichtigt keinen Fehler darstellt. Zum anderen bestanden Abweichungen in der Konfiguration, insbesondere bei der Zuordnung zwischen dem Testkonto und einer Organisation.
+
+Dieser zweite Punkt ist charakteristisch für das gewählte Ablagekonzept: Ob ein Benutzer Dokumente sieht, hängt von einer Kette ab, die über das Anmeldetoken, die Organisationszuordnung und das Metadatum am Kundenordner läuft. Ist ein Glied dieser Kette in einer Umgebung nicht korrekt eingerichtet, ist das Ergebnis eine leere, aber fehlerfreie Seite. Nach Bereinigung der Konfiguration funktionierte die Anzeige wie vorgesehen.
+
+Rückblickend hätte eine kurze Prüfliste für die Inbetriebnahme in einer neuen Umgebung — Speicher erreichbar, Testdaten vorhanden, Rolle vergeben, Organisationszuordnung gesetzt — den ersten Abschnitt der Abnahme deutlich verkürzt.
+
+\subsection{Funktionale Prüfung}
+
+Nach Behebung der Umgebungsprobleme fand am 24.~August die eigentliche funktionale Abnahme statt. Geprüft wurden die Paginierung, das Verhalten der Suche, die Sprungmarken der Freigabelinks, das Fehlerverhalten, die Behandlung von Verknüpfungsdateien und der Download.
+
+Diese Prüfung verlief im Wesentlichen erfolgreich. Festgehalten wurde, dass einzelne Bestandteile zu diesem Zeitpunkt auf der Testumgebung noch nicht verfügbar waren — was daran lag, dass der letzte Pull Request noch offen war (siehe Abschnitt~\ref{sec:folder-management}). Die gefundenen Abweichungen wurden als eigene Fehlerberichte erfasst statt in der Abnahmediskussion abgehandelt zu werden.
+
+\subsection{Der gefundene Fehler}
+
+Aus der funktionalen Prüfung ging ein Fehlerbericht hervor. Er betrifft nicht die Funktion, sondern die Konsistenz: Das Suchfeld des Dokumentenbereichs blendet nach einer Eingabe eine kleine Schaltfläche zum Leeren des Feldes ein. Diese Schaltfläche existiert auf den übrigen Houston-Seiten nicht, weshalb die Suche sich abweichend darstellt und verhält.
+
+Für sich betrachtet ist die Schaltfläche eine sinnvolle Erleichterung. Der Fehler liegt nicht in ihrer Funktion, sondern darin, dass sie an dieser einen Stelle existiert und sonst nirgends. Genau das verletzt die Konsistenzanforderung (NFA-4).
+
+Der Befund ist ein gutes Beispiel für die Grenzen der vorgelagerten Prüfstufen. Weder ein Unit-Test noch ein Code-Review hätte ihn finden können: Der erste prüft das Modul gegen sich selbst, der zweite den Quelltext einer Änderung. Sichtbar wird die Abweichung erst, wenn jemand die neue Seite neben den bestehenden Seiten betrachtet — und das leistet nur ein Abnahmetest durch eine Person, die die übrige Anwendung kennt. Der Fehler wurde für den folgenden Sprint eingeplant.

chapters/qa/code-reviews.tex

@@ -1,7 +1,44 @@
 \section{Code-Reviews}
 \label{sec:code-reviews}
 
-% TODO: 11 PRs (2154–2196), Reviewer: Timo Walter, Sarah Hinzmann, Robin Noack
-% Reviewfunde: zentrale Auth über Program.cs, keyed Settings, 403 statt 404,
-% Slug-Naming-Constraints (IBM-Doku), Fehlerbehandlung statt stiller leerer Seite
-% Tabelle~\ref{tab:pull-requests} im Anhang
+\subsection{Umfang}
+
+Die Umsetzung verteilte sich auf elf Pull Requests mit insgesamt 113 Diskussionssträngen. Tabelle~\ref{tab:pull-requests} im Anhang enthält die vollständige Übersicht mit Laufzeiten, Reviewern und Strangzahl. Kein Pull Request wurde abgelehnt oder verworfen; sämtliche abgeschlossenen erhielten eine Freigabe. Die inhaltliche Auseinandersetzung fand also durchgängig in den Diskussionssträngen statt und nicht über Ablehnungen.
+
+Dass kein einziger Pull Request verworfen werden musste, ist kein Zufall. Die vorgelagerte Klärung — die Feature-Analyse im Juni und die Backlog-Durchsicht im Juli — hatte die fachlichen Fragen so weit beantwortet, dass keine Implementierung auf einer falschen Annahme beruhte. Der Aufwand der Vorklärung zahlte sich damit unmittelbar aus.
+
+\subsection{Prüftiefe und Risiko}
+
+Bemerkenswert ist die Verteilung der Diskussionsstränge über die Pull Requests. Sie ist stark ungleich, folgt aber erkennbar dem Risiko der jeweiligen Änderung.
+
+Die intensivste Prüfung erfuhren der Einzeldownload mit 30 und die Freigabelinks mit 23 Diskussionssträngen — also genau die beiden Arbeiten, bei denen ein Fehler zur Offenlegung von Kundendokumenten geführt hätte. Der Document Explorer als Grundlage des Moduls folgt mit 21 Strängen. Am unteren Ende steht die PDF-Vorschau mit zwei Strängen: eine reine Darstellungsfunktion, die auf bereits geprüften Bausteinen aufsetzt und keine eigene Sicherheitsentscheidung trifft.
+
+Diese Verteilung entstand ohne ausdrückliche Vorgabe. Sie deutet darauf hin, dass die Reviewer ihre Aufmerksamkeit intuitiv dorthin lenkten, wo ein Fehler teuer gewesen wäre — ein Verhalten, das sich mit einer formalen Vorgabe kaum hätte erzwingen lassen.
+
+\subsection{Wiederkehrende Themen}
+
+Über alle Diskussionsstränge hinweg lassen sich fünf Muster erkennen.
+
+\textbf{Sicherheit und Eingabeprüfung.} Der größte Anteil entfiel auf die Frage, ob eine von außen kommende Angabe ausreichend geprüft wird. Konkret betraf das die Pfadprüfung beim Download, den Verzicht auf das Durchreichen von Dateiströmen zugunsten zeitlich begrenzter Zugriffs-URLs, den bewussten Ausschluss benutzerdefinierter Symbole aus der Vorschau und den Grundsatz, keine Dateiinhalte über nicht authentifizierte Pfade auszuliefern.
+
+\textbf{Kompatibilität vor Ideallösung.} Mehrfach wurde eine technisch sauberere Lösung zugunsten einer verlässlich funktionierenden verworfen. Das prägnanteste Beispiel ist die Bereitstellung der Vorschaubilder als Rastergrafik, weil die Vektorvariante von verbreiteten Messengern nicht zuverlässig dargestellt wird (siehe Abschnitt~\ref{sec:pdf-preview}).
+
+\textbf{Abgrenzung statt Ausweitung.} Im Review erkannte Probleme wurden konsequent als neue Backlog Items erfasst, statt sie im laufenden Pull Request mitzuerledigen. Das betrifft die Speicherabfrage aus dem Explorer und der Suche, die Typsuche und die Nebenläufigkeit im Lookup. Dieses Vorgehen hielt die Pull Requests auf ihren jeweiligen Gegenstand begrenzt und machte zugleich sichtbar, dass die Probleme erkannt und nicht übergangen wurden.
+
+\textbf{Struktur und Wartbarkeit.} Wiederkehrend waren Hinweise auf auszulagernde Skripte in Seitenvorlagen, auf fehlertolerantes statt manuelles Auswerten von Aufzählungswerten, auf überflüssige Kommentare und auf uneinheitliche Benennungen.
+
+\textbf{Fachliche Klärung im Review.} In mehreren Fällen führte die Diskussion nicht zu einer Änderung am Code, sondern am Backlog Item. So wurde die Antwort bei fehlender Berechtigung von 404 auf 403 geändert und festgehalten, dass auch ein einzeln ausgewähltes Dokument als Archiv ausgeliefert wird. Das Review leistete damit auch Anforderungsarbeit — ein Hinweis darauf, dass sich Akzeptanzkriterien im Vorfeld nie vollständig formulieren lassen.
+
+\subsection{Wechsel der Reviewer}
+
+Über die Projektlaufzeit wechselte der Hauptreviewer zweimal: \emph{Timo Walter} prüfte die fünf Pull Requests der Anfangsphase, \emph{Sarah Hinzmann} übernahm Anfang August, \emph{Robin Noack} die Schlussphase. Zusätzlich beteiligte sich \emph{Hanna Ebner} an den frühen Diskussionen.
+
+Der Wechsel war organisatorisch bedingt, hatte aber einen erkennbaren fachlichen Effekt. Die Schwerpunkte verschoben sich mit den Personen: Die frühen Reviews befassten sich stark mit Architektur, Sicherheit und der Grundsatzfrage der Speicherabfrage; die mittleren mit Bedienung und Wartbarkeit; die späten mit Benennung, Fehlertoleranz und Codestil. Ein durchgehend gleicher Reviewer hätte diese Bandbreite vermutlich nicht abgedeckt, weil sich Aufmerksamkeitsmuster mit der Zeit verfestigen. Zugleich verteilte der Wechsel das Wissen über das neue Modul im Team.
+
+\subsection{Kritische Betrachtung des Vorgehens}
+
+Ein Punkt verdient eine selbstkritische Bewertung. Am 27.~Juli wurden vier Pull Requests am selben Tag eröffnet, ein fünfter folgte am Tag darauf. Da sie inhaltlich aufeinander aufbauten, ließ sich nur der erste zeitnah abschließen; die übrigen blieben zwischen zwei und drei Wochen offen und wurden erst nach dem Zusammenführen ihrer jeweiligen Vorgänger fertiggestellt.
+
+Die in Abschnitt~\ref{sec:architecture} beschriebene Verkettung machte die einzelnen Änderungen zwar gut prüfbar, verlagerte den Aufwand aber an das Ende: Der überwiegende Teil der Zusammenführungen fällt in die Woche vom 18. bis 21.~August — unmittelbar vor Abnahme und Produktivsetzung. Diese Ballung erhöhte den Druck in einer ohnehin kritischen Phase.
+
+Rückblickend wäre ein stärker sequenzielles Vorgehen vorzuziehen gewesen: jeweils einen Pull Request abschließen, bevor der nächste eröffnet wird. Der Vorteil paralleler Bearbeitung — nie auf ein Review warten zu müssen — erwies sich als geringer als erwartet, weil die inhaltliche Abhängigkeit ein echtes paralleles Vorankommen ohnehin verhinderte.

chapters/qa/releases.tex

@@ -1,5 +1,26 @@
-\section{Releases}
+\section{Auslieferung}
 \label{sec:releases}
 
-% TODO: DEV / TEST / PROD je eigener Bucket, Rollenvergabe vor Release
-% PR 2196 noch aktiv bei Dokumentationsabgabe
+\subsection{Umgebungen}
+
+Die Auslieferung folgt dem in Houston etablierten dreistufigen Weg über Entwicklungs-, Test- und Produktivumgebung. Für den Dokumentenbereich kommt hinzu, dass jede Stufe einen eigenen Speicher besitzt (siehe Abschnitt~\ref{sec:s3-client}). Eine Auslieferung umfasst damit nicht nur den Anwendungsstand, sondern setzt voraus, dass der zugehörige Speicher eingerichtet, erreichbar und in der jeweiligen Umgebung korrekt hinterlegt ist.
+
+Diese zusätzliche Abhängigkeit war der Grund dafür, dass die Bereitstellung der Infrastruktur (Abschnitt~\ref{sec:infrastructure}) bereits im Approval-Termin als Voraussetzung am ersten Backlog Item vermerkt worden war.
+
+\subsection{Rollen als Teil der Auslieferung}
+
+Der zweite umgebungsabhängige Bestandteil ist die Anwendungsrolle. Sie muss je Umgebung vorhanden sein und den betreffenden Personen zugewiesen werden. Beides ist kein Bestandteil des ausgelieferten Anwendungsstands, sondern eine begleitende Maßnahme.
+
+Wie in Abschnitt~\ref{sec:acceptance-testing} beschrieben, führte genau dieser Punkt zu Verzögerungen im Abnahmetest. Vor der Produktivsetzung wurde er entsprechend ausdrücklich behandelt: Gegenstand der Abstimmung am 20.~August war die Frage, ob sämtliche Funktionen des Moduls tatsächlich hinter der Rolle liegen, bevor der Stand produktiv geht.
+
+Diese Prüfung ist nicht überflüssig, weil das Modul mehrere Einstiegspunkte besitzt. Neben der Dokumentenliste existieren eigene Routen für Download und Freigabe. Wäre eine davon versehentlich nicht von der zentralen Richtlinie erfasst, bliebe sie ohne Anmeldung erreichbar, ohne dass dies in der Bedienoberfläche sichtbar wäre — der Menüpunkt wäre weiterhin ausgeblendet. Die in Abschnitt~\ref{sec:architecture} beschriebene zentrale Registrierung der Autorisierung ist genau die Maßnahme, die diesen Fehler unwahrscheinlich macht; die Prüfung vor der Auslieferung bestätigt ihn zusätzlich.
+
+\subsection{Stand bei Abgabe}
+
+Zum Zeitpunkt der Erstellung dieser Dokumentation stellt sich der Auslieferungsstand wie folgt dar. Zehn der elf Pull Requests waren zusammengeführt; der überwiegende Teil davon in der Woche vom 18.~bis 21.~August. Der Dokumentenbereich war damit in seinen Kernfunktionen — Liste, Typisierung, Suche, Filter, Paginierung, Downloads, Vorschau, Freigabelinks und Verknüpfungsdateien — ausgeliefert.
+
+Nicht abgeschlossen war die Ordnerverwaltung mit dem neuen Kundenordner-Lookup. Der zugehörige Pull Request war fachlich fertiggestellt und ohne offene inhaltliche Anmerkungen, aber noch nicht freigegeben und nicht zusammengeführt. Bis dahin bleibt der Lookup bei dem in Abschnitt~\ref{sec:document-explorer} beschriebenen linearen Verfahren — funktional korrekt, aber mit der bekannten Skalierungsschwäche.
+
+Ebenfalls offen sind das Backlog Item zur Nebenläufigkeit, das bewusst abgegrenzt und für die Umsetzung freigegeben ist, sowie der aus der Abnahme hervorgegangene Fehlerbericht, der für den folgenden Sprint eingeplant ist.
+
+Der Dokumentenbereich ist damit in Betrieb, aber nicht in allen Teilen abgeschlossen. Diese Unterscheidung ist für die Bewertung des Projekts wesentlich und wird in Abschnitt~\ref{sec:target-comparison} aufgegriffen.

chapters/qa/test-strategy.tex

@@ -1,4 +1,14 @@
 \section{Teststrategie}
 \label{sec:test-strategy}
 
-% TODO: Unit-Tests mit gemocktem IAmazonS3, Abnahmetests durch Maria-Lena Andersz
+Die Qualitätssicherung stützte sich auf drei Stufen, die unterschiedliche Fehlerarten adressieren und zu unterschiedlichen Zeitpunkten wirken.
+
+\textbf{Unit-Tests} sichern die Logik ab, die sich isoliert prüfen lässt und deren Verhalten von außen schwer zu beobachten ist. Das betrifft im vorliegenden Modul vor allem die Auflösung des Kundenordners und die Behandlung von Pfaden. Diese Tests laufen bei jedem Übersetzungsvorgang und melden Abweichungen unmittelbar.
+
+\textbf{Code-Reviews} prüfen Entwurf, Lesbarkeit und Sicherheitseigenschaften. Sie erfassen Fehlerarten, für die ein automatisierter Test nicht formuliert werden kann, weil das erwartete Verhalten erst im Gespräch entsteht — etwa die Frage, ob eine bestimmte Information auf einem nicht authentifizierten Pfad ausgeliefert werden darf.
+
+\textbf{Abnahmetests} prüfen gegen die Akzeptanzkriterien aus fachlicher Sicht und in der tatsächlichen Umgebung. Sie erfassen Fehler, die aus dem Zusammenspiel mit der Konfiguration, den Berechtigungen und den realen Daten entstehen — also genau jene Klasse von Problemen, die in Unit-Tests und Reviews systematisch unsichtbar bleibt.
+
+Der Zuschnitt der automatisierten Tests folgte dabei bewusst dem Risiko und nicht einer Abdeckungsvorgabe. Für den Kundenordner-Lookup wurde die Testabdeckung ausdrücklich als Akzeptanzkriterium in das Backlog Item aufgenommen; für Darstellungsfunktionen wie die PDF-Vorschau geschah dies nicht. Die Begründung liegt im Verhältnis von Fehlerwahrscheinlichkeit zu Fehlerwirkung: Ein Fehler im Lookup führt zur Anzeige fremder Dokumente oder zu Datenverlust und ist im laufenden Betrieb schwer zu bemerken. Ein Fehler in der PDF-Vorschau ist beim ersten Aufruf offensichtlich.
+
+Diese Priorisierung hat allerdings eine Kehrseite, die sich im Abnahmetest zeigte: Fehler in den Bereichen ohne automatisierte Abdeckung wurden erst dort gefunden. Abschnitt~\ref{sec:acceptance-testing} greift dies auf.

chapters/qa/unit-tests.tex

@@ -1,6 +1,32 @@
 \section{Unit-Tests}
 \label{sec:unit-tests}
 
-% TODO: DocumentsServiceTests — gemocktes IAmazonS3
-% Pfade: Fast-Path, Fallback, Rename, Create, Kollision, Fehlerfall
-% Abbildung~\ref{fig:documents-service-tests}
+\subsection{Testbarkeit durch Kapselung}
+
+Die Voraussetzung für die Testbarkeit des Moduls wurde bereits mit dem Entwurf geschaffen. Da der Speicherzugriff ausschließlich über die Schnittstelle des SDK erfolgt, lässt sich diese in Tests durch eine Attrappe ersetzen. Die Tests laufen damit ohne Netzwerkverbindung, ohne Zugangsdaten und ohne einen realen Speicher.
+
+Dies ist mehr als eine Bequemlichkeit. Erst die Attrappe erlaubt es, Zustände herzustellen, die sich real kaum oder nur mit erheblichem Aufwand erzeugen ließen — etwa einen Kundenordner mit falschem Namen, aber korrektem Metadatum, oder einen Ordner ohne jedes Metadatum. Genau diese Randfälle sind es, die in der Praxis selten auftreten und deren Behandlung deshalb ohne Test unbemerkt fehlerhaft bleiben könnte.
+
+\subsection{Abgedeckte Pfade}
+
+Die Tests des Kundenordner-Lookups bilden die in Abschnitt~\ref{sec:lookup-decision} beschriebenen Wege einzeln ab: den Direktzugriff bei korrektem Ordnernamen, den Kollisionsfall, die Rückfallebene mit anschließender Umbenennung, das Anlegen eines fehlenden Kundenordners sowie das Ignorieren eines Ordners ohne gültiges Metadatum. Für jeden Weg wird nicht nur das Ergebnis geprüft, sondern auch, welche Zugriffe auf den Speicher tatsächlich erfolgt sind — beim Direktzugriff etwa, dass genau eine Metadatenabfrage und keine Auflistung stattgefunden hat.
+
+Dieser Punkt verdient Beachtung: Die Anforderung an den Lookup war keine funktionale, sondern eine über den Aufwand. Ein Test, der lediglich das richtige Präfix prüft, würde auch dann bestehen, wenn die Implementierung weiterhin alle Ordner durchliefe. Die eigentliche Eigenschaft — dass der Regelfall mit einem einzigen Zugriff auskommt — lässt sich nur über die beobachteten Aufrufe der Attrappe prüfen.
+
+\subsection{Testdaten}
+
+Ein Reviewfund betraf die verwendeten Testdaten. \emph{Timo Walter} merkte an, dass in den Tests reale Kundennamen verwendet wurden, und schlug Platzhalter vor.
+
+Der Hinweis ist inhaltlich klein, in der Sache aber richtig. Testdaten sind Quelltext: Sie liegen in der Versionsverwaltung, sind für jeden mit Zugriff auf das Repository lesbar und bleiben dort dauerhaft erhalten, auch wenn sie später geändert werden. Ein realer Kundenname in einem Testfall stellt damit eine unnötige Offenlegung dar — unnötig deshalb, weil der Test mit einem Platzhalternamen exakt denselben Zweck erfüllt. Die Testdaten wurden entsprechend ersetzt.
+
+\subsection{Ein Test, der das Falsche prüfte}
+
+Der aufschlussreichste Fund der gesamten Qualitätssicherung betraf einen Test, der bestand — aber aus dem falschen Grund. \emph{Timo Walter} bemerkte beim Lesen, dass der Prüfling bereits in der ersten Zeile abbrach, weil die Auswertung des Pfades einen unbekannten Typbezeichner vorfand und daraufhin kein Ergebnis lieferte. Der Test endete damit, bevor die eigentlich zu prüfende Logik überhaupt erreicht war.
+
+Aus dieser Beobachtung leitete er zusätzlich einen vermuteten Fehler im Code ab: Ein Dokument, das unmittelbar im Kundenordner liegt und damit keinen Typ trägt, dürfe nicht dazu führen, dass die Auswertung scheitert.
+
+Die anschließende Klärung ergab, dass der Code korrekt war, der Test jedoch missverständlich benannt und aufgebaut. Geprüft wurde nämlich nicht der untypisierte Fall, sondern eine Sicherheitseigenschaft: dass ein Benutzer, der den Kundennamen selbst als Pfadbestandteil in die Adresse schreibt, kein Ergebnis erhält und dass daraufhin keine Anfrage an den Speicher abgesetzt wird. Der Kundenname darf im relativen Pfad niemals vorkommen — genau das war der Gegenstand des Tests.
+
+Der Vorgang ist in zweifacher Hinsicht lehrreich. Zum einen zeigt er, dass ein bestandener Test keine Aussage über die geprüfte Eigenschaft trifft, solange nicht sichergestellt ist, dass er den relevanten Codepfad überhaupt erreicht — ein Test, der aus dem falschen Grund grün ist, ist wertlos und zugleich gefährlich, weil er Sicherheit suggeriert. Zum anderen zeigt er den Wert des Reviews für Testcode: Der Fund war nicht durch Ausführen zu erzielen, sondern nur durch Lesen.
+
+Als Konsequenz wurde die Absicht des Tests explizit gemacht. Genau diese Anforderung — dass ein Test ohne den zugehörigen Fix fehlschlagen muss — wurde später auch in die Akzeptanzkriterien des Folgeitems zur Nebenläufigkeit aufgenommen (siehe Abschnitt~\ref{sec:race-conditions}).