Websites & Web-Anwendungen
Die Aussage „die Webseite funktioniert nicht“ ist technisch zu unbestimmt. Für einen belastbaren Befund müssen erwartetes Verhalten, konkrete Vorbedingungen, Prüfablauf, Umgebung und beobachtete Abweichung so dokumentiert werden, dass die Prüfung nachvollziehbar wiederholt werden kann.
Kurzantwort
Ein Webfehler wird technisch belastbar, wenn ein konkretes Soll-Kriterium unter dokumentierten Bedingungen einem reproduzierbaren Ist-Verhalten gegenübergestellt wird.
Bei dynamischen Webanwendungen müssen dabei Browserzustand, Sitzung, Datenstand, Netzwerkkommunikation und gegebenenfalls Cache-Einflüsse berücksichtigt werden. Ein einzelner fehlgeschlagener Versuch genügt nicht automatisch für eine allgemeine Fehleraussage.
Von der Beanstandung zum reproduzierbaren Webfehler-Befund
1. Technisches Soll in prüfbare Kriterien übersetzen
Ohne nachvollziehbares Soll kann eine beobachtete Abweichung nicht technisch bewertet werden.
Anforderungen müssen beobachtbares Verhalten beschreiben
Ein Prüfkriterium sollte erkennen lassen, welche Eingabe unter welchen Vorbedingungen zu welchem erwarteten Ergebnis führen soll.
Rechtliche Mangelbegriffe sind nicht das technische Soll
Welche Rechtsfolge eine Abweichung hat, ist von der technischen Feststellung zu trennen. Die Untersuchung beschreibt zunächst Verhalten und Abweichung.
2. Vorbedingungen und Testschritte reproduzierbar dokumentieren
Webfehler können von Zuständen abhängen, die bei einer späteren Wiederholung sonst unbemerkt abweichen.
Browser, Sitzung und Datenzustand gehören zum Prüfkontext
Authentifizierung, gespeicherte Zustände, Eingabedaten und bereits ausgeführte Schritte können das Ergebnis verändern.
Automatisierung kann Wiederholbarkeit unterstützen
WebDriver-basierte Abläufe können definierte Browseraktionen standardisiert ausführen. Sie ersetzen jedoch nicht die fachliche Festlegung geeigneter Prüfkriterien.
3. UI-, DOM- und HTTP-Befunde getrennt dokumentieren
Eine sichtbare Abweichung kann mehrere technische Ebenen betreffen.
Fehlerbild und Kommunikationsbefund sind unterschiedliche Evidenz
Ein sichtbarer Hinweis im Frontend kann gemeinsam mit einer fehlgeschlagenen API-Kommunikation auftreten. Beide Befunde sollten zunächst getrennt dokumentiert werden.
Fehlender Request kann selbst ein technischer Befund sein
Wenn ein erwarteter Netzwerkrequest nach einer definierten Aktion nicht entsteht, kann dies für die Fehlerlokalisierung relevant sein.
4. Wiederholungen und Kontrollläufe einsetzen
Mehrere Läufe helfen zu unterscheiden, ob eine Abweichung stabil, zustandsabhängig oder intermittierend auftritt.
Kontrollierte Variation grenzt Einflussfaktoren ein
Browserzustand, Cache oder Eingabedaten können gezielt variiert werden, sofern jeweils nur nachvollziehbare Bedingungen verändert werden.
Ein bestandener Kontrolllauf widerlegt nicht jede Fehlerhypothese
Intermittierende oder zustandsabhängige Fehler können unter anderen Bedingungen weiterhin bestehen. Die Generalisierung muss durch die Daten getragen sein.
| Element | Zu dokumentieren | Zweck |
|---|---|---|
| Soll | erwartetes beobachtbares Verhalten | Vergleichsmaßstab |
| Vorbedingungen | Browser, Sitzung, Daten, Zustand | Reproduzierbarkeit |
| Schritte | konkrete Aktionen in Reihenfolge | Wiederholbarkeit |
| Ist | sichtbarer, DOM- und HTTP-Befund | technische Feststellung |
| Wiederholung | Ergebnisse mehrerer Läufe | Robustheit der Aussage |
5. Nicht reproduzierbare oder intermittierende Fehler einordnen
Fehlende Reproduktion ist ein Befund über den Prüfversuch, nicht automatisch über die historische Nichtexistenz eines Fehlers.
Fehlende historische Bedingungen begrenzen die Aussage
Wenn damalige Daten-, Cache-, Browser- oder Backendzustände nicht mehr rekonstruierbar sind, muss diese Unsicherheit ausdrücklich dokumentiert werden.
Was bedeutet es, wenn ein behaupteter Fehler nicht reproduziert werden kann?
Ein erfolgloser Reproduktionsversuch belegt zunächst nur, dass der Fehler unter den dokumentierten Prüfbedingungen nicht beobachtet wurde.
Ob der Fehler historisch bestand oder unter anderen Bedingungen auftreten kann, hängt von der verfügbaren Evidenz und der Rekonstruierbarkeit der damaligen Umgebung ab.
6. Technische Abweichung und rechtliche Würdigung trennen
Der sachverständige Befund beschreibt das nachgewiesene technische Verhalten und seinen Prüfkontext.
Aus einer Abweichung folgt nicht automatisch ein Rechtsmangel
Die technische Untersuchung kann feststellen, dass ein definiertes Soll-Kriterium unter dokumentierten Bedingungen nicht erfüllt wird. Die rechtliche Bewertung bleibt davon getrennt.
Ist der Webfehler-Befund technisch belastbar?
- Ist das Soll als beobachtbares Kriterium formuliert?
- Sind Eingabedaten und Vorbedingungen dokumentiert?
- Ist Browser- und Sitzungszustand bestimmt?
- Sind die Prüfschritte in Reihenfolge dokumentiert?
- Sind UI-, DOM- und HTTP-Befunde getrennt erfasst?
- Wurde der Versuch sinnvoll wiederholt?
- Sind Kontrollbedingungen oder Alternativerklärungen geprüft?
- Ist die rechtliche Würdigung vom technischen Befund getrennt?
Konstruiertes Beispiel
Eine Schaltfläche soll nach erfolgreicher Eingabe einen Bestellvorgang auslösen. Unter einem definierten Testkonto entsteht reproduzierbar kein API-Request. Der technische Befund lautet zunächst, dass der erwartete Kommunikationsschritt unter diesen Bedingungen nicht ausgeführt wurde.
Das Beispiel dient ausschließlich der methodischen Erläuterung und beschreibt kein reales Mandat oder Kundenprojekt.
Quellen und fachliche Grundlage
- Technische Primärquelle W3C WebDriver Recommendation (05.06.2018) . Standardisierte Browsersteuerung als Grundlage reproduzierbarer browserbasierter Prüfabläufe. Geprüft am 20.10.2026.
- Technische Primärquelle RFC 9110 – HTTP Semantics . HTTP-Methoden, Statuscodes, Headerfelder, Repräsentationen und Semantik von HTTP-Nachrichten. Geprüft am 20.10.2026.
- Technische Primärquelle WHATWG HTML Living Standard . HTML-Dokumente, Parsing, Browsing-Kontext und browserseitige Webplattform. Geprüft am 20.10.2026.
- Technische Primärquelle WHATWG DOM Standard . Dokumentbaum, Nodes, Events und technische DOM-Struktur. Geprüft am 20.10.2026.
- Technische Primärquelle WHATWG Fetch Standard . Browserseitige Requests, Responses, Redirects, CORS- und Fetch-Verarbeitung. Geprüft am 20.10.2026.
- Technische Primärquelle RFC 9111 – HTTP Caching . Technische Regeln für HTTP-Caches, Frische, Validierung und gespeicherte Responses. Geprüft am 20.10.2026.
- Eigene Fachliteratur Mathias Ellmann: Von Code zu Lösungen im Software Engineering mit Java . Eigene Fachliteratur als fachlicher Hintergrund im Software Engineering; kein unabhängiger Primärnachweis für die jeweils herangezogene externe Webspezifikation.
- Eigene fachliche Einordnung Die konkrete Untersuchungsstruktur, Auswahl der Belege, Gegenhypothesen und Aussagegrenzen wird aus der jeweiligen technischen Fragestellung und der tatsächlich verfügbaren Untersuchungsgrundlage abgeleitet.
Weiterführende Beiträge
Softwaremängel technisch untersuchen: Soll-Ist-Vergleich
Frontend, Backend und API rekonstruieren
Browser-, Geräte- und Umgebungsabhängigkeit
Technische Untersuchung von Websites und Web-Anwendungen
Wenn der technische Zustand oder das Verhalten einer Website beziehungsweise Webanwendung untersucht werden soll, können Untersuchungsgegenstand, Prüfstand und relevante Nachweise zunächst sachverständig eingegrenzt werden.
Software-Gutachten ansehen