chapters: Fliesstext auf 57 reine Textseiten kuerzen

Zwei Kompressionsdurchgaenge ueber Kapitel 2-7. Entfernt wurden
Redundanzen, Meta-Kommentare, Ueberklaerungen und Fuellsaetze;
Fakten, Namen, Daten, Entscheidungen samt Begruendung sowie alle
Abbildungen und Tabellen bleiben unveraendert.

Reine Textseiten: 78 -> 57 (Woerter 19613 -> 12451).
Gesamt-PDF: 138 -> 116 Seiten.

chapters/qa/acceptance-testing.tex

@@ -3,38 +3,36 @@
 
 \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 fachliche Abnahme übernahm \emph{Maria-Lena Andersz}. Sie begann am 13.~August 2026 und zog sich mit Unterbrechungen bis zum 25.~August; geprüft wurde gegen die Akzeptanzkriterien der 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.
+Die Abnahme zerfiel in zwei Abschnitte: zunächst Zugriffs- und Konfigurationsprobleme, erst danach die funktionale Prüfung.
 
 \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.
+Der Menüpunkt „Dokumente" erschien nicht. Die Ursache lag nicht im Code, sondern in der Berechtigungsvergabe — der Testerin war die Anwendungsrolle nicht zugewiesen. Das Verhalten entsprach der Spezifikation: Ohne Rolle ist der Menüpunkt unsichtbar (siehe Abschnitt~\ref{sec:authorization}).
 
-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 offen: Die Rolle war Ende Juli für die Entwicklungsumgebung beantragt worden; dass ihre Vergabe an Testende ein eigener Schritt ist, war weder in Akzeptanzkriterien noch Übergabe festgehalten. Eine rollenbasierte Funktion bringt Anforderungen mit, die über den Code hinausgehen.
 
-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.
+Hier bewährte sich die 403-Antwort (Abschnitt~\ref{sec:authorization}): Bei 404 wäre für die Testerin nicht unterscheidbar gewesen, ob die Seite fehlt oder die Berechtigung.
 
 \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.
+Nach Klärung der Berechtigung wurden keine Dokumente angezeigt. Auch hier lag die Ursache in der Umgebung: Es fehlten Testdateien im Speicher, und die Zuordnung zwischen Testkonto und Organisation war nicht korrekt konfiguriert.
 
-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.
+Das ist charakteristisch für das Ablagekonzept: Ob ein Benutzer Dokumente sieht, hängt von einer Kette ab — Anmeldetoken, Organisationszuordnung, Metadatum am Kundenordner. Ist ein Glied falsch, zeigt die Seite keine Dokumente, aber auch keinen Fehler. Nach Bereinigung funktionierte die Anzeige.
 
-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.
+Eine Prüfliste für die Inbetriebnahme — Speicher erreichbar, Testdaten vorhanden, Rolle vergeben, Organisationszuordnung gesetzt — hätte diesen Abschnitt 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.
+Am 24.~August fand die funktionale Abnahme statt: Paginierung, Suchverhalten, Sprungmarken der Freigabelinks, Fehlerverhalten, Verknüpfungsdateien und 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.
+Die Prüfung verlief überwiegend erfolgreich; einzelne Bestandteile waren nicht verfügbar, da der letzte Pull Request offen war (siehe Abschnitt~\ref{sec:folder-management}). Abweichungen wurden als Fehlerberichte erfasst.
 
 \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.
+Ein Fehlerbericht: Das Suchfeld blendet nach Eingabe eine Schaltfläche zum Leeren ein, die auf den übrigen Houston-Seiten nicht existiert — eine Abweichung in Darstellung und Verhalten.
 
-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).
+Die Schaltfläche ist eine sinnvolle Erleichterung; der Fehler liegt darin, dass sie nur an dieser Stelle existiert, was NFA-4 (Konsistenz) verletzt.
 
-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.
+Weder Unit-Test noch Code-Review hätten ihn finden können; sichtbar wird die Abweichung erst beim Vergleich mit den bestehenden Seiten — das leistet nur ein Abnahmetest durch eine Person, die die Anwendung kennt. Der Fehler wurde für den folgenden Sprint eingeplant.

chapters/qa/code-reviews.tex

@@ -3,42 +3,40 @@
 
 \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.
+Die Umsetzung verteilte sich auf elf Pull Requests mit 113 Diskussionssträngen (Tabelle~\ref{tab:pull-requests} im Anhang). Kein Pull Request wurde abgelehnt; sämtliche erhielten eine Freigabe. Die inhaltliche Auseinandersetzung fand durchgängig in den Diskussionssträngen statt.
 
-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.
+Dass kein Pull Request verworfen wurde, ist kein Zufall: Die vorgelagerte Klärung — Feature-Analyse im Juni, Backlog-Durchsicht im Juli — hatte die fachlichen Fragen so weit beantwortet, dass keine Implementierung auf einer falschen Annahme beruhte.
 
 \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 Verteilung der Diskussionsstränge folgt dem Risiko: Die intensivste Prüfung erfuhren Einzeldownload (30 Stränge) und Freigabelinks (23) — die Arbeiten, bei denen ein Fehler Kundendokumente offengelegt hätte. Der Document Explorer folgt mit 21 Strängen, die PDF-Vorschau mit zwei: eine Darstellungsfunktion ohne eigene Sicherheitsentscheidung.
 
-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.
+Die Verteilung entstand ohne Vorgabe — die Reviewer lenkten ihre Aufmerksamkeit intuitiv dorthin, wo ein Fehler teuer gewesen wäre.
 
 \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{Sicherheit und Eingabeprüfung.} Der größte Anteil entfiel auf die Prüfung externer Angaben: Pfadprüfung beim Download, zeitlich begrenzte Zugriffs-URLs statt Dateiströme, Ausschluss benutzerdefinierter Symbole aus der Vorschau und der Grundsatz, keine Inhalte ü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{Kompatibilität vor Ideallösung.} Mehrfach wurde eine technisch sauberere Lösung zugunsten einer verlässlicheren verworfen — etwa 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{Abgrenzung statt Ausweitung.} Erkannte Probleme wurden als neue Backlog Items erfasst statt im laufenden Pull Request miterledigt — etwa Speicherabfrage, Typsuche und Nebenläufigkeit. Das hielt die Pull Requests begrenzt und machte die Probleme sichtbar.
 
-\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{Struktur und Wartbarkeit.} Wiederkehrend: auszulagernde Skripte, fehlertolerantes Auswerten von Aufzählungswerten, überflüssige Kommentare, 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.
+\textbf{Fachliche Klärung im Review.} In mehreren Fällen änderte die Diskussion nicht den Code, sondern das Backlog Item — etwa den Statuscode bei fehlender Berechtigung (403 statt 404) und die Festlegung, dass auch einzelne Dokumente als Archiv ausgeliefert werden. Das Review leistete damit Anforderungsarbeit.
 
 \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.
+Der Wechsel war organisatorisch bedingt, hatte aber einen fachlichen Effekt: Frühe Reviews befassten sich mit Architektur, Sicherheit und Speicherabfrage; mittlere mit Bedienung und Wartbarkeit; späte mit Benennung, Fehlertoleranz und Codestil. Ein gleicher Reviewer hätte diese Bandbreite vermutlich nicht abgedeckt; zugleich verteilte der Wechsel das Wissen über das 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.
+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 zwei bis drei Wochen offen.
 
-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.
+Die in Abschnitt~\ref{sec:architecture} beschriebene Verkettung machte die Änderungen gut prüfbar, verlagerte den Aufwand aber ans Ende: Der überwiegende Teil der Zusammenführungen fällt in die Woche vom 18. bis 21.~August — unmittelbar vor Abnahme und Produktivsetzung.
 
-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.
+Rückblickend wäre sequenzielles Vorgehen vorzuziehen gewesen, da die inhaltliche Abhängigkeit echtes paralleles Vorankommen ohnehin verhinderte.

chapters/qa/releases.tex

@@ -3,24 +3,24 @@
 
 \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.
+Die Auslieferung folgt dem in Houston etablierten dreistufigen Weg über Entwicklungs-, Test- und Produktivumgebung. Jede Stufe besitzt einen eigenen Speicher (siehe Abschnitt~\ref{sec:s3-client}); eine Auslieferung setzt voraus, dass dieser eingerichtet, erreichbar und 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.
+Deshalb wurde die Infrastrukturbereitstellung (Abschnitt~\ref{sec:infrastructure}) bereits im Approval-Termin als Voraussetzung vermerkt.
 
 \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.
+Die Anwendungsrolle muss je Umgebung vorhanden sein und den betreffenden Personen zugewiesen werden — kein Bestandteil des 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.
+Dieser Punkt führte im Abnahmetest zu Verzögerungen (Abschnitt~\ref{sec:acceptance-testing}). Vor der Produktivsetzung wurde daher am 20.~August geprüft, ob sämtliche Funktionen des Moduls hinter der Rolle liegen.
 
-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.
+Die Prüfung ist nötig, weil das Modul mehrere Einstiegspunkte besitzt: Wäre eine Route nicht von der zentralen Richtlinie erfasst, bliebe sie ohne Anmeldung erreichbar, ohne dass dies sichtbar wäre. Die zentrale Registrierung (Abschnitt~\ref{sec:architecture}) macht diesen Fehler unwahrscheinlich; die Prüfung bestätigt dies.
 
 \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.
+Bei Abgabe waren zehn der elf Pull Requests zusammengeführt, überwiegend 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.
+Nicht abgeschlossen war die Ordnerverwaltung mit dem neuen Kundenordner-Lookup. Der Pull Request war fachlich fertig, aber nicht freigegeben; bis dahin bleibt das in Abschnitt~\ref{sec:document-explorer} beschriebene lineare Verfahren — funktional korrekt, aber mit bekannter 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.
+Ebenfalls offen sind das Backlog Item zur Nebenläufigkeit sowie der Fehlerbericht aus der Abnahme, 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.
+Der Dokumentenbereich ist in Betrieb, aber nicht vollständig abgeschlossen (Abschnitt~\ref{sec:target-comparison}).

chapters/qa/test-strategy.tex

@@ -1,14 +1,14 @@
 \section{Teststrategie}
 \label{sec:test-strategy}
 
-Die Qualitätssicherung stützte sich auf drei Stufen, die unterschiedliche Fehlerarten adressieren und zu unterschiedlichen Zeitpunkten wirken.
+Die Qualitätssicherung stützte sich auf drei Stufen.
 
-\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{Unit-Tests} sichern isoliert prüfbare Logik ab — hier vor allem Kundenordner-Auflösung und Pfadbehandlung. Sie laufen bei jedem Übersetzungsvorgang.
 
-\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{Code-Reviews} prüfen Entwurf, Lesbarkeit und Sicherheitseigenschaften — Fehlerarten, für die kein automatisierter Test formulierbar ist, etwa ob eine 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.
+\textbf{Abnahmetests} prüfen gegen die Akzeptanzkriterien in der tatsächlichen Umgebung. Sie erfassen Fehler aus dem Zusammenspiel von Konfiguration, Berechtigungen und realen Daten — eine Klasse, die in Unit-Tests und Reviews 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.
+Die automatisierten Tests folgten dem Risiko, nicht einer Abdeckungsvorgabe. Für den Kundenordner-Lookup war Testabdeckung ausdrücklich als Akzeptanzkriterium aufgenommen; für die PDF-Vorschau nicht. Ein Fehler im Lookup führt zur Anzeige fremder Dokumente oder Datenverlust und ist im Betrieb schwer zu bemerken; ein Fehler in der 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.
+Diese Priorisierung hat eine Kehrseite: Fehler in Bereichen ohne automatisierte Abdeckung wurden erst im Abnahmetest gefunden (Abschnitt~\ref{sec:acceptance-testing}).

chapters/qa/unit-tests.tex

@@ -3,30 +3,26 @@
 
 \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.
+Da der Speicherzugriff über die SDK-Schnittstelle 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.
+Die Attrappe erlaubt Zustände, die sich real kaum erzeugen ließen — etwa einen Kundenordner mit falschem Namen, aber korrektem Metadatum, oder einen Ordner ohne Metadatum. Gerade diese Randfälle könnten ohne Test unbemerkt fehlerhaft bleiben.
 
 \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.
+Die Tests bilden die in Abschnitt~\ref{sec:lookup-decision} beschriebenen Wege einzeln ab: Direktzugriff, Kollisionsfall, Rückfallebene mit Umbenennung, Anlegen eines fehlenden Kundenordners und Ignorieren eines Ordners ohne gültiges Metadatum. Geprüft wird nicht nur das Ergebnis, sondern auch die Speicherzugriffe — beim Direktzugriff etwa, dass genau eine Metadatenabfrage und keine Auflistung stattfand.
 
-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.
+Die Anforderung an den Lookup war keine funktionale, sondern eine über den Aufwand. Ein Test, der nur das richtige Präfix prüft, bestünde auch, 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 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.
+\emph{Timo Walter} merkte an, dass reale Kundennamen in den Tests verwendet wurden, und schlug Platzhalter vor. Der Hinweis ist klein, in der Sache aber richtig: Testdaten liegen in der Versionsverwaltung und bleiben dauerhaft lesbar; ein realer Kundenname ist eine unnötige Offenlegung, da der Test mit Platzhaltern denselben Zweck erfüllt. Die Daten wurden 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.
+\emph{Timo Walter} bemerkte beim Lesen, dass ein Test bestand, aber aus dem falschen Grund: Der Prüfling brach in der ersten Zeile ab, weil die Pfadauswertung einen unbekannten Typbezeichner vorfand — die eigentlich zu prüfende Logik wurde nie erreicht.
 
-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.
+Er leitete einen vermuteten Fehler ab: Ein Dokument ohne Typ dürfe die Auswertung nicht scheitern lassen. Die Klärung ergab, dass der Code korrekt, der Test aber missverständlich benannt war. Geprüft wurde eine Sicherheitseigenschaft: dass ein Benutzer, der den Kundennamen als Pfadbestandteil in die Adresse schreibt, kein Ergebnis erhält und keine Anfrage an den Speicher ausgelöst wird.
 
-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 zeigt zweierlei: Ein Test, der aus dem falschen Grund grün ist, ist wertlos, weil er Sicherheit suggeriert. Der Fund war nicht durch Ausführen zu erzielen, sondern nur durch Lesen — er belegt den Wert des Reviews für Testcode.
 
-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}).
+Als Konsequenz wurde die Absicht des Tests explizit gemacht. Diese Anforderung — dass ein Test ohne den Fix fehlschlagen muss — wurde in die Akzeptanzkriterien des Folgeitems zur Nebenläufigkeit aufgenommen (siehe Abschnitt~\ref{sec:race-conditions}).