0qln/itc.pidi-3-docs
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chapters: Fliesstext auf 57 reine Textseiten kuerzen

Browse Source 
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.
This commit is contained in:
0qln
2026-08-25 23:02:17 +02:00
parent 1a3d0820da
commit ce0875f29b
38 changed files with 351 additions and 445 deletions
Download Patch File Download Diff File Expand all files Collapse all files
chapters/qa/test-strategy.tex
+6 -6
View File
@@ -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}).