Bloodrabbid/qa-software-testing

Softwaretesten: UI, API, manuell und automatisiert

Grundlage ist das Handbuch „Qualität entscheidet alles: Das vollständige Handbuch zum Softwaretesten“ (Roman Surkov). Alles, was mit [außerhalb des Buches] gekennzeichnet ist, stammt aus anderen Quellen (Liste am Ende) oder aus der allgemeinen Praxis. Präsentiere dies als Ergänzung, nicht als Position des Autors.

Wann anwenden

• „Teste die Funktion / den Bildschirm / die App / die API“, „Erstelle eine Checkliste / Testfälle“, „Melde einen Bug“.
• Überprüfung von Pflichtenheft, Figma-Design oder Swagger noch vor der Entwicklung (Shift-Left).
• Auswahl, was und wie automatisiert werden soll; Lasttestszenario; Release-Bereitschaftsbericht.
• Für Videospiele verwende den Skill qa-game-testing, übernimm aber die allgemeine Basis (Testdesign, Artefakte) von hier.

Schritt 0: Bestimme den Arbeitsmodus

Anfrage	Was ausgeben
Pflichtenheft / Design vorhanden, Code noch nicht vorhanden	Anforderungs-Review (Schritt 1) + vorab erstellte Checkliste
„Teste“ ohne Details	Zerlegung nach „BKLUZBAK“ (Schritt 2) → Checkliste → Testfälle für komplexe Dinge
Live-Website / App verfügbar	Durchführung der Checks, Bug-Reports, abschließender TRR
API / Swagger / cURL	BINMEN + POISED (Schritt 6), Requests-Sammlung
„Was soll automatisiert werden?“, Flaky Tests, Playwright	Plan nach Pyramide und Regeln für Autotests (Schritt 8)
API-Sicherheitscheck	OWASP API Top 10 Matrix (Schritt 6)
LLM-Feature (Chatbot, Generierung)	Prüfschichten und Referenzsatz (Schritt 9)
Freies Testen einer neuen Funktion	SBTM-Sessions-Charts + SFDIPOT (Schritt 2)

Zuerst positive Tests (Happy Path), dann negative. Bei positiven Tests können Prüfungen zusammengefasst werden, bei negativen Tests ein ungültiger Parameter pro Prüfung.

Schritt 1: Anforderungstests (Shift-Left)

Ein Fehler wird nach der 1–10–100-Regel teurer: Die Korrektur im Pflichtenheft kostet 1, im Code das 3- bis 8-fache, durch QA gefunden das 20- bis 80-fache, in der Produktion das 100-fache und mehr. Beginne also mit dem Dokument.

Kriterien für eine gute Anforderung (bei jeder Verletzung – Kommentar im Dokument): Vollständigkeit (Grenzfälle und Fehler sind beschrieben), Widerspruchsfreiheit (Text widerspricht nicht dem Design), Eindeutigkeit, Korrektheit, Testbarkeit („Wie kann ich das prüfen?“), Atomarität (eine Idee).

Füllwörter – „schnell“, „benutzerfreundlich“, „intuitiv“, „flexibel“, „angemessen“, „bei Bedarf“. Schreibe sie in Messbares um: „Suche schnell“ → „Ergebnis ≤ 1,5 s bei 1000 gleichzeitigen Anfragen“.

Wenn kein Pflichtenheft vorhanden ist, wird das erwartete Ergebnis abgeleitet aus: Designs und Prototypen → Mitbewerbern → Gesetzen und Vorschriften (GDPR, PSD2) → Best Practices und gesundem Menschenverstand (E-Mail-Validierung, Rate-Limit, Telefonmasken) → Gespräch mit dem Entwickler oder Analysten.

Wie man Anforderungen hinterfragt: Fragen zu Grenzen (maximale Länge, verbotene Zeichen, Verbindungsabbruch, zwei Benutzer klicken gleichzeitig); Blockdiagramm oder Mindmap des Pfades (ein Pfeil, der ins Leere führt, ist ein nicht beschriebenes Szenario); Testfälle direkt beim Lesen (kann kein Testfall geschrieben werden – ein Bug im Pflichtenheft gefunden).

Orakel FEW HICCUPPS [außerhalb des Buches, M. Bolton und J. Bach] – womit sonst belegt werden kann, dass das Verhalten problematisch ist, wenn keine oder eine unvollständige Spezifikation vorliegt. Das Produkt muss übereinstimmen mit: Familiar problems (wiederholt keine bekannten Fehlertypen), Explainability (Verhalten erklärbar), World (nicht im Widerspruch zur Realität), History (mit früheren Versionen), Image (Unternehmensimage), Comparable products (Alternativen), Claims (Aussagen: Pflichtenheft, Werbung, Hilfe), User desires (vernünftige Benutzerwünsche), Product (mit sich selbst: eine Aktion – überall gleiches Verhalten), Purpose (Zweck), Statutes and standards (Gesetze und Standards). Nenne im Bug-Report das Orakel: „widerspricht der vorherigen Version“, „widerspricht der Hilfe“ – so lässt sich leichter gegen „das ist kein Bug“ argumentieren.

Missing Feature: Wenn die Funktion fehlt und im Pflichtenheft nicht vorgesehen ist, ist es kein Bug, sondern eine Verbesserung / Feature Request. Konflikte werden durch eine Funktionsmatrix gelöst: Web – vorhanden, iOS – vorhanden, Android – nicht vorhanden.

Schritt 2: Zerlegung der Aufgabe „Teste“

Funktionale Tests beantworten die Frage „WAS tut es“, nichtfunktionale „WIE“. Nichtfunktionale Vektoren werden nach der Eselsbrücke „BKLUZBAK“ durchgegangen:

• B – Sicherheit (XSS, SQL-Injection, Zugriffsrechte)
• K – Lokalisierung
• L – Benutzerfreundlichkeit (Usability)
• U – Grafische Benutzeroberfläche (GUI)
• Z – Installation (nur was installiert wird: Desktop, Mobile, Konsolen)
• B – Barrierefreiheit (a11y)
• A – Leistung (client- und serverseitig)
• K – Konfiguration und Kompatibilität

Füge Whittelors Erkundungstouren für die freie Suche hinzu: Reiseführer (Hauptfunktionen), Hinterhöfe (seltene Einstellungen), Kurier (ein Objekt durch alle Status), Geld (Warenkorb und Bezahlung), Nachtarbeiter (Hintergrundaufgaben), Müllmann („Abbrechen“, „Zurücksetzen“), Aufdringlicher (100 Wiederholungen einer Aktion), Schlechte Gegend (historisch problembehaftete Module), Museum (alter, lange nicht angefasster Code).

Was gibt es im Produkt überhaupt – SFDIPOT [außerhalb des Buches, HTSM von J. Bach]: Structure (woraus es besteht: Dateien, Module, Builds), Function (was es tut), Data (was eingegeben, gespeichert, ausgegeben wird; leer, riesig, beschädigt), Interfaces (UI, API, Import/Export, Integrationen), Platform (OS, Browser, Hardware, externe Dienste), Operations (wie es tatsächlich genutzt wird: häufige Szenarien, unerfahrene und bösartige Benutzer), Time (Timeouts, Parallelität, Ereignisreihenfolge, Zeitzonen, lange Laufzeit). Gehe die sieben Wörter durch – du erhältst eine Coverage-Karte, die BKLUZBAK nicht liefert.

Exploratives Testen in Sitzungen (SBTM) [außerhalb des Buches, J. und J. Bach]. Eine Sitzung dauert 60–90 Minuten ohne Ablenkungen, sie hat eine Charta: „Untersuche mit <Werkzeuge, Techniken, Daten>, um zu entdecken.“ Ergebnis ist ein Sitzungsbericht: was abgedeckt wurde, gefundene Bugs, Fragen, Risiken, Anteil der Zeit für Testen / Bugmeldung / Umgebungseinrichtung und eine kurze Besprechung mit dem Lead. So wird freies Testen nachvollziehbar: Es ist sichtbar, was geprüft wurde und was noch aussteht.

Schritt 3: Testdesign-Techniken

Reihenfolge: zuerst das Grundgerüst aus Äquivalenzklassen + Grenzwertanalyse + Entscheidungstabellen, dann Verstärkung durch Error Guessing.

1. Äquivalenzklassen (EP): ein Wert aus jeder gültigen und ungültigen Klasse.
2. Grenzwerte – nur 3W-Grenzwertanalyse: an jeder Grenze min-1, min, min+1 nehmen (und ebenso für max). 2W-Grenzwertanalyse übersieht einen Tippfehler des Operators X == 10 statt X >= 10: die Punkte 9 und 10 bestehen, 11 schlägt fehl. Beispiel: Zugang 18–100 Jahre → -1, 0, 1, 16, 17, 18, 99, 100, 101. Für Geldbeträge ist die Schrittweite die kleinste Einheit (0,01 €).
3. Kombinatorik: 1-wise (≈50% der Bugs, Express), Pairwise – Standard (70–90%), 3-wise für Finanzen (≈95%), vollständige Abdeckung nur für kritische Systeme. Erstelle niemals eine Pairwise-Matrix im Kopf: generiere sie mit einem Tool (PICT, falls installiert, sonst pip install allpairspy --break-system-packages) und überprüfe mit einem Skript, dass alle Paare abgedeckt sind. Wo anwenden: Katalogfilter, Taschenrechner, Bezahlung × Versand, Export (Format × Kodierung × Trennzeichen). Für Cross-Browser-Testing kein Pairwise verwenden (siehe Schritt 5).
4. Entscheidungstabellen: wenn im Pflichtenheft viele „wenn / und / oder / außer“ vorkommen, 2–5 binäre Bedingungen. Streiche unmögliche Kombinationen, und Regeln mit gleichem Ergebnis fasse zu einem Fall zusammen. Typische Einsatzorte: Rabatte und Gutscheincodes, Rollenmatrix, abhängige Formularfelder (juristische Person → INN und KPP Pflicht), Bestellstatus.
5. Zustände und Übergänge: alles, was einen Lebenszyklus und Timeouts hat. Prüfe ungültige Übergänge, Timeout-Ablauf (Reservierung ohne Bezahlung geht zurück in „Frei“), Einmaligkeit von Token (erneutes Zurücksetzen des Passworts mit altem Link), Abbruch in jedem Schritt.
6. Error Guessing – Katalog typischer Fallstricke:
   • Unsaubere Eingabe: nur Leerzeichen, Leerzeichen um E-Mail herum, U+200B, Emojis, Anführungszeichen, Hieroglyphen, 10.000 Zeichen aus der Zwischenablage;
   • Wiederholungen und Wettlaufsituationen: dreifacher Klick auf „Bezahlen“, „Zurück“ nach der Transaktion, letzter Artikel von zwei Personen gekauft;
   • Unterbrechungen: Netzwerkabbruch bei 99 %, Schließen des Tabs während des Zahlungsvorgangs;
   • Daten und Zahlen: 29.02. in einem Nicht-Schaltjahr, Geburtsdatum in der Zukunft, 00.00.0000, Menge −1, 0, 999.999;
   • Umgebung: Session nach 3 Stunden Leerlauf abgelaufen, .exe mit Erweiterung .jpg, Datei mit 500 MB.

Schritt 4: Artefakte

Checkliste (ID, Prüfung, Status) – Standard. Testfall – für komplexe Logik, Onboarding und Weitergabe an die Automatisierung.

Felder eines Testfalls: ID, Name, Priorität, Vorbedingung (immer ausfüllen), Schritte, Testdaten, erwartetes Ergebnis; nach der Durchführung – tatsächliches Ergebnis und Status (Bestanden / Fehlgeschlagen / Blockiert / Übersprungen).

Regeln: In den Schritten nur Aktionen des Testers, Systemreaktionen im erwarteten Ergebnis; Schritte atomar („E-Mail eingeben“, „Passwort eingeben“, „Anmelden klicken“ – drei Schritte); ein Fall = eine Prüfung; Fälle sind unabhängig voneinander (Vorbereitung geht in die Vorbedingung oder wird über API erledigt); Detaillierungsgrad angemessen, ohne „Maus bewegen“; Priorität Hoch – Geld und Autorisierung, Niedrig – Kosmetik, Rest (≈80%) Mittel.

Testsuite – Ordner pro Modul mit verschachtelten Suiten nach Funktionen; modulübergreifende Prüfungen liegen im Root der Suite. Testlauf – Durchlauf einer Menge auf einem bestimmten Build und einer Umgebung mit Status. Testplan (auf Anfrage): Umfang (drin / draußen), Strategie und Umgebung, Einstiegskriterien, Aussetzungs- und Ausstiegskriterien, Ressourcen und Zeitplan, Risiken mit Plan B.

Bug-Report

Titel:        [Wo] Was passiert, unter welcher Bedingung
              Beispiel: [Gutscheinfenster] Fehler 500 bei Eingabe eines abgelaufenen Gutscheins
Umgebung:     Prod/Stage, Browser und Version, OS; bei Mobile Modell und genaue OS-Version; URL
Vorbedingung: Benutzerrolle, Seite, vorbereitete Daten
Schritte:     1. … 2. … (nur Aktionen, minimale Kette)
Erwartet:     konkret, mit Verweis auf Pflichtenheft oder Design
Tatsächlich:  was passiert ist
Schweregrad:  Blocker / Kritisch / Schwer (Workaround vorhanden) / Geringfügig / Trivial – technische
              Bewertung, wird vom QA festgelegt
Priorität:    Hoch / Mittel / Niedrig – Dringlichkeit für das Unternehmen (wird von PO/PM festgelegt)
Reproduzierbarkeit: Immer (10/10) oder Gelegentlich (z.B. 1/10)
Workaround:   alternativer Weg, falls vorhanden
Anhänge:      Screenshot für Statisches, Video für Dynamisches, Konsole-Logs oder HAR für Backend

Regeln: 1 Bug = 1 Ticket; vor dem Erstellen nach Duplikaten suchen; sofort anlegen; neutraler Ton; keinen Fix im Ticket erfinden; so schreiben, dass nach einem Monat anhand der Beschreibung die Behebung überprüft werden kann. Schweregrad und Priorität sind unabhängig (Tippfehler im Logo: Trivial / Sofort).

Testabschlussbericht (TRR)

Minimales Wasser, maximale Zahlen und eine klare Go / No-Go-Empfehlung:

TESTABSCHLUSSBERICHT BUILD vX.Y
Geplant: N Fälle: Bestanden a (a%) · Fehlgeschlagen b (b%) · Blockiert c (c%)
Defekte: BUG-… – Kern (Priorität) [Link] …
Blockiert: welcher Block und durch welche Bugs
QA-Empfehlung: Veröffentlichung NICHT empfohlen / empfohlen mit Bedingungen …

Schritt 5: UI: Formulare, GUI, Benutzerfreundlichkeit, Barrierefreiheit, Kompatibilität, Lokalisierung

Formulare und Eingabefelder

• Text: gültiger Wert; leeres Pflichtfeld; genau max; max+1; Sonderzeichen ' " < > / ; : @ # $ % ^ & * ( ) _ +; Emojis (Absturz bei utf8mb4); nur Leerzeichen, führende, nachgestellte und innere Leerzeichen (trim erwartet); Mischung aus Kyrillisch, Lateinisch, Hieroglyphen und RTL; F5 speichert die Eingabe (außer Passwort und Captcha); Doppelklick auf „Senden“ sendet nicht zwei Requests; U+200B.
• Passwort: Maskierung; wird bei Neuladen und Fehler gelöscht; Prüfung auf schwaches Passwort und auf Übereinstimmung mit Benutzername oder E-Mail; Einfügen aus der Zwischenablage und aus dem Passwort-Manager; „Augen“-Symbol schaltet Passwort ↔ Text um.
• Auswahl und Hochladen: sinnvolle Standardwerte (Zustimmung nicht vorab markiert – GDPR); Klick auf Label schaltet Checkbox um; „alle auswählen / alle abwählen“; verbotene Erweiterungen (.exe, .php), Datei 0 Byte und 100 MB+, Fortschrittsbalken.
• UX Validierung: Inline-Prüfung bei Verlassen des Feldes, eingegebener Wert wird bei Fehler nicht zurückgesetzt, Feld hervorgehoben und Ursache mit CTA daneben; Format vorab angegeben („TT.MM.JJJJ“); ein Feld – ein Wert; Erfolgsbildschirm mit Nummer, Status und nächstem Schritt; „Zurück“ in einem mehrschrittigen Formular speichert die Daten oder ist explizit verboten.
• Plus BKLUZBAK: Tab / Umschalt+Tab / Eingabetaste, Safari und Mobile, Fehlerübersetzungen, XSS, SQL, CSRF, Rate Limit.

GUI: Abgleich mit Design (Figma + DevTools)

Beginne mit Common Components – ein Fix in einer gemeinsamen Komponente repariert Dutzende von Bildschirmen. Maße – Erweiterung Pixel Measurement (Breite „kleiner als Design“ bei geöffneten DevTools – responsiv, kein Bug). Schriften und Farben – Elements → Computed (font-size, background-color → HEX). Abstände – Option/Alt in Figma gegen Box Model. Animationen – Command Palette → Show Animations, auf 10–25 % verlangsamen. Overlay – PerfectPixel bei 50 % Deckkraft. Eine Abweichung von 1 Pixel ist kein Bug (Subpixel-Rundung), wenn das Layout nicht verrutscht ist.

Benutzerfreundlichkeit (Usability)

Prüfe anhand der 10 Heuristiken von Nielsen: Systemstatus, Benutzersprache, Kontrolle und Rückgängig, Plattformstandards (HIG / Material), Fehlervermeidung, Wiedererkennen statt Erinnern, Beschleuniger, Minimalismus, verständliche Fehler, Hilfe. Für ein erwachsenes Publikum: Schrift nicht kleiner als 12 pt, Kontrast, große Ziele. Keine nativen Muster brechen: Doppeltippen, systemeigene Gesten am Bildschirmrand. „Rückgängig“ mit 5 Sekunden ist besser als der Dialog „Sind Sie sicher?“.

Barrierefreiheit (WCAG, POUR)

Schnelldurchlauf: Lighthouse (nur Barrierefreiheit) → axe DevTools → IBM Equal Access → ANDI (Tab-Reihenfolge und Elementnamen) → Kontrast (AA ≥ 4,5:1, AAA ≥ 7:1). Text über Bild oder Farbverlauf mit der Pipette in DevTools überprüfen: Scanner nehmen die Farbe des benachbarten Tags. Manuell: komplette Arbeit ohne Maus, sichtbarer und nicht überdeckter Fokus, Alt-Texte bei informativen Bildern, nichts blinkt schneller als 3 Mal pro Sekunde, prefers-reduced-motion wird respektiert, Screenreader (NVDA / VoiceOver). Simulationen – Web Disability Simulator.

Kompatibilität

Die Matrix basiert auf Daten: eigene Analysen → regionale Statistiken → StatCounter (und auf das Risiko einer unzureichenden Abdeckung hinweisen). Schaue auf den Umsatz pro Plattform, nicht nur auf den Traffic. Verwerfe Enden < 0,5 %. Gruppiere nach Engine: Chrome und Edge unter Windows – ein Chromium; alle Browser unter iOS – WebKit, aber Safari unter iOS separat testen (eigene Layout-Bugs). Verteile Regression proportional zu den Anteilen (200 Fälle × Anteil der Gruppe), nicht per Pairwise „Browser × Fall“ (das wären 1400 Durchläufe). Fehlende Geräte deckst du mit Ferntests oder Emulatoren ab (BrowserStack, Sauce Labs).

Schritt 6: API-Tests (Backend, REST, GraphQL, SOAP)

Wichtige Frage zuerst: Ist die Dokumentation aktuell? Widerspricht das tatsächliche Verhalten der Spezifikation (Contract) oder ist die API selbst instabil? Im zweiten Fall ist das ein Bug im Backend.

BSRPG-Umsetzungsmatrix (BINMEN + POISED) [außerhalb des Buche] – alle API-Checks auf einem Blick:

• B – Bestellung / Schema: entspricht die tatsächliche Antwort dem Vertrag (Schema-Validierung)?
• I – Idempotenz: erneutes Senden derselben Anfrage führt zu keinem Duplikat.
• N – Nichtdeterminismus: zufällige Werte, Zeitstempel, Fehlermeldungen – immer dieselbe Antwort?
• M – Methoden: nur vorhandene Methoden (POST zum Anlegen, GET zum Lesen, DELETE zum Löschen). GET ändert keine Daten.
• E – Fehler: Status 2xx für Erfolg, 4xx für Client-Fehler (400 Fehler, 401 nicht autorisiert, 403 verboten, 404 nicht gefunden, 409 Konflikt, 422 unverarbeitbare Entität), 5xx für Server-Fehler (503 nicht verfügbar). Alle Fehlermeldungen sind menschenlesbar, ohne Stacktraces. Verwende niemals 200 + {„error“:true}.
• N – Nicht standardkonform: unvollständige Felder, Feldnamen, die nicht der Konvention entsprechen (camelCase, PascalCase, snake_case), inkonsistente Datentypen ("1" statt 1), falsches Datumsformat.
• P – Menge: leere Liste, 1 Element, 1000 Elemente. Paginierung für jede Liste.
• O – Optionen: CORS, HTTP-Methoden.
• I – Integrationen: Abhängigkeit von externen Diensten (fällt einer aus – kommt ein sinnvoller Fehler?) Mock oder WireMock für die Tests.
• S – Sicherheit: Rate Limit (wie viele Anfragen pro Sekunde / Minute), limitierte Antwortgröße, keine sensiblen Daten in der Antwort (Token, Passwörter, Kreditkarten).
• E – Zustände: Erstellen → Aktualisieren → Löschen. Abhängige Objekte: Löschen übergeordneter sperrt Kind-Objekte. Statusübergänge: nicht erlaubte Übergänge geben einen Fehler 4xx zurück.
• D – Daten: SQL Injection, NoSQL Injection, XSS in Feldern, Befehle, Typumwandlung (String → Zahl mit der lokalen Notation 3.14 und 3,14).

Zusätzlich Abwesenheit voreingestellter IDs – nicht voraussetzen, dass ein Objekt mit ID=1 existiert. Jeder Test erstellt selbstständig Testdaten über POST / Resource und löscht sie nach Abschluss.

Kontrakt-Tests: Das Backend garantiert die Struktur der Antwort; die gesamte Verarbeitung der vom Backend empfangenen Daten – sowohl auf dem Frontend als auch auf dem Backend (von anderen Diensten) – validiert die Struktur erneut. Prüfe, ob die API OpenAPI / Swagger verwendet (auch intern).

OWASP API Top 10 (Sicherheitsmatrix)

Kategorie	Was zu prüfen
API1 – Verletzung der Objektberechtigung	Ändere die ID in der Anfrage (aus URL oder Body) auf eine andere: Zugriff auf die Bestellung eines anderen, Fremddokument; Bug – Critical
API2 – Verletzung der Benutzerauthentifizierung	Token ohne Verfallsdatum, einfaches Passwort, Registrierung ohne E-Mail-Bestätigung; Bug – High
API8 – Injection	SQL, NoSQL, Command, LDAP, XPath; Bug – Critical
API9 – Fehlerhafte Ressourcenverwaltung	Body > 100 MB, Batch mit 10.000 IDs; Bug – Medium
…	eine vollständige Liste auf owasp.org/API-Security

Verwende für API-Tests curl / Postman / Bruno (manuell) und pytest + requests (automatisiert). Strukturiere die Testsammlung wie folgt:

/tests/api/
  ├── conftest.py        # Fixtures (Client, Basis-URL, Auth-Token, Datenbereinigung)
  ├── test_health.py     # Healthcheck, Status, Ping
  ├── test_users.py      # CRUD + Felder + Fehler + Rollen
  ├── test_orders.py     # Bestellungen, Zahlungen, Statusübergänge
  └── test_security.py   # OWASP-Checks

Schritt 7: Nichtfunktionale Tests (Leistung, Sicherheit, Installation, Lokalisierung)

Leistung: Bestimme die Arten – Last (normale Nutzung), Ausdauer (30+ Minuten unter Last, um Speicherlecks zu finden), Spitze (plötzlicher Anstieg), Volumen (große Datenmengen). Verwende JMeter / k6 / Locust. Metriken: Antwortzeit (p95, p99), Fehlerrate, Durchsatz. Erfolgskriterien: Antwortzeit ≤ 2 Sekunden unter Standardlast, ≤ 200 ms für API, Fehlerrate < 1 %.

Sicherheit: Zusätzlich zu OWASP API Top 10 – grundlegende Web-Checks: HTTPS + HSTS header, XSS-geschützte Formulare, SQL-Injection-Block, Cookie-Flags (Secure, HttpOnly, SameSite), offene Ports im Staging, sichere Passwortspeicherung (gehasht), keine sensiblen Daten in URLs, proper Session-Logout.

Installation: Für Desktop und Mobile – eine vollständige Installation, sauber entfernen, Update überschreibt ältere Version, Rollback bei fehlgeschlagenem Update, Konfiguration nach der Installation, Speicherplatz belegt ≤ deklariert, Update bricht Benutzerdaten nicht ab.

Lokalisierung: Prüfe, ob Texte aus dem Code genommen werden (keine Hardcodierung), UI-Elemente passen in die Textlänge (deutsche Texte sind länger), Datums- und Währungsformat (DE: 01.01.2024, 1.234,56 €), Adressen und Telefone, Übersetzungen in Sprachen mit anderen Alphabeten, gemischte Sprache (DE-System + EN-Input).

Schritt 8: Automatisierung und Flaky Tests

Wann automatisieren

Die Wahl erfolgt gemäß der Pyramide: viele schnelle Unit-Tests → weniger API-Tests → noch weniger UI-Tests. Begründe die Wahl: kritische Funktionen + stabile (oft ausgeführte) Tests = gute Kandidaten; kurze manuelle Scans + einmalige Prüfungen = keine Automatisierung.

Werkzeuge: Frontend – Playwright (empfohlen), Cypress, Puppeteer. Backend – pytest + requests (super für API-Tests + Datenbank-Cleaning).

Auswahlkriterien:

• kritischer Pfad: Anmeldung → Hauptfunktion → Bezahlung → Abmeldung (automatisieren)
• Datenabhängigkeit: schwer vorzubereiten (nicht automatisieren)
• visuelle Kontrolle: Screenshot-Vergleich (Playwright-visual-regression) – für statische Blöcke
• einmalige Tests: ein Test pro Build – automatisieren; Tests, die nur einmal bei einer neuen Funktion ausgeführt werden – löschen
• Tests des nächsten Schritts: zu oft fehlschlagend → manuell umwandeln

Grundregeln für Autotests

1. Unabhängigkeit: Tests hängen nicht voneinander ab (jeder erzeugt seine eigenen Daten). Ein Test = ein unabhängiger Lauf.
2. Stabilität: keine festen Wartezeiten (time.sleep()). await page.wait_for_selector() mit Timeout.
3. Isolation: mocke externe Dienste (WireMock, MSW), um Tests deterministisch zu machen.
4. Datenbereinigung: nach dem Test, unabhängig vom Ergebnis: teardown_method oder @pytest.fixture(autouse).
5. Atomare Asserts: ein Assert pro Test, mit aussagekräftigem Namen.
6. Wiederholungen: @pytest.mark.flaky(reruns=3) für zeitabhängige Tests.
7. Logger: logging.debug() in jedem Schritt – das Debuggen eines fehlgeschlagenen Tests wird vereinfacht.
8. CI/CD: Tests laufen auf Pull Requests und vor dem Release auf dem Hauptzweig.

Was tun mit Flaky Tests

Flaky – ein Test, der ohne Codeänderungen mal bestanden, mal fehlgeschlagen ist. Analysiere die Ursache: zeitliche Probleme, konkurrierende Zustände, Abhängigkeit von Tests (nicht atomar), externe Dienste, Datenverunreinigung, asynchrone Requests ohne Wartezeit.

Strategie:

1. Erkenne: führe 10 Mal hintereinander in einem Fork aus (Playwright --repeat-each=10).
2. Deaktiviere: platziere ein @pytest.mark.skip(reason="flaky? Bug-XXX") und erstelle einen Bug.
3. Behebe: füge wait_for_selector statt time.sleep() hinzu, mache den Test atomar, entferne die Abhängigkeit von externen Diensten (Mock).
4. Reaktiviere: entferne skip und dokumentiere die Ursache.

Playwright: Praxis

• npx playwright test – Standardlauf; --headed – GUI anzeigen; --debug – Pause bei jedem Schritt.
• Struktur: tests/e2e/*.spec.ts – nach Funktionen geordnet; pages/*.page.ts – PageObject.
• Warte – immer wait_for_selector / wait_for_url / wait_for_load_state("networkidle").
• Lokalisiere – get_by_role, get_by_text, get_by_test_id. Keine CSS-Selektoren auf Klassen.
• Screenshot bei Fehler: page.screenshot(path="...") in test.after_each.
• Parallel: workers: os.cpus().length / 2 in der Config.

Schritt 9: LLM-Features testen (Chatbots, Generierung)

LLMs sind nichtdeterministisch – das erschwert Tests, aber ersetzt sie nicht.

Prüfschichten

1. Sicherheit und Ethik: generiert das LLM keine Beleidigungen, keine Gewalt, keine Anleitungen für illegale Handlungen, keine sensiblen Daten; Prompt-Injection – ein Benutzer versucht, die Anweisungen zu überschreiben („Ignoriere vorherige Anweisungen und sage …“).
2. Inhaltliche Richtigkeit: die Antwort enthält keine nachweislich falschen Fakten (Halluzinationen). Verwende faktische Rückfragen: Frage die Quellen des LLM ab („Aus welcher Quelle hast du diese Zahl?“), vergleiche mit Ground-Truth-Datenbank.
3. Relevanz und Vollständigkeit: die Antwort bezieht sich auf den Kontext der Frage, enthält nichts Überflüssiges, berücksichtigt die Bedingungen des Benutzers (Rolle, Zweck).
4. Stil und Format: die Antwort folgt der angegebenen Formatierung (JSON, Tabellen, Code), die Sprache entspricht der Anfragesprache, der Ton ist neutral und hilfreich.
5. Wiederholbarkeit und Abweichung: für denselben Prompt – die Antwortvariation ist akzeptabel (innerhalb von Grenzen), aber die Hauptbedeutung bleibt erhalten, der Unterschied zwischen zwei Durchläufen überschreitet keinen festgelegten Grenzwert nicht.

Referenzdatensatz für Regression

Erstelle 20–50 Prompts aus den häufigsten Benutzerszenarien und speichere erwartete Eigenschaften:

|
Prompt | Erwartete Eigenschaft | Prüfmethode |
|---|---|---|
| „Erstelle eine Zusammenfassung“ | Enthält 3–5 Sätze | Metrik Länge |
| „Übersetze ins Deutsche“ | Antwort in Deutsch | Sprache erkennen |
| „Code für Login optimieren“ | Enthält try/except oder error handling | Regex |

Teste jeden Prompt 3 Mal – wenn mindestens 2 von 3 die Eigenschaft erfüllen, gilt der Check als bestanden.

Zusätzliche LLM-Checks

• Inhaltsfilter: Gib eine Anfrage mit offensichtlich verbotenem Inhalt – das LLM sollte antworten „Ich kann diese Frage nicht beantworten“ (oder ähnlich).
• Kontextlimit: Frage nach 5000 Zeichen – das LLM schneidet den Text ab oder fasst ihn zusammen (kein Fehler, aber dokumentiere das Verhalten).
• Geschwindigkeit: antworte innerhalb von 15 Sekunden (Threshold).
• System-Prompt-Injection: Der Benutzer gibt [system] oder ### Anweisungen ein – das LLM sollte diese nicht befolgen.

Schritt 10. Liste der Quellen [außerhalb des Buches]

1. OWASP API Security Top 10 – owasp.org/API-Security
2. Playwright-Dokumentation – playwright.dev
3. M. Bolton, J. Bach – „FEW HICCUPPS“ (Heuristiken für Orakel), HTSM (Heuristic Test Strategy Model), SFDIPOT, SBTM (Session-Based Test Management)
4. J. Whittaker – Erkundungstouren aus „Exploratory Software Testing“
5. W. Grieskamp, N. Kicillof – Pairwise-Testing (PICT von Microsoft)
6. Barrierefreiheit: WCAG 2.1, POUR-Prinzipien, axe DevTools, NVDA, VoiceOver
7. Playwright – visuelles Regressionstesten, Flaky-Test-Strategie
8. K. Wiegers – „1–10–100“-Regel der Fehlerkosten, Kriterien für gute Anforderungen
9. Nielsen Norman Group – 10 Usability-Heuristiken
10. StatCounter, BrowserStack, Sauce Labs – Kompatibilitätsdaten und Tools

Hinweise zum Skill

• Verwende für die Arbeit mit dem Benutzer die Benutzersprache (wenn der Benutzer auf Deutsch fragt – antworte auf Deutsch).
• Wenn du einen Bug meldest – gib unverzüglich ein Ticket mit einem Titel aus, der mit der Priorität von „CRITICAL“ / „HIGH“ / „MEDIUM“ / „LOW“ beginnt – das erleichtert dem Menschen die Sortierung.
• Wenn der Benutzer nach einem „vollständigen Testplan“ oder TRR fragt – erstelle eine Vorlage mit tatsächlichen Zahlen (oder Fragezeichen, wo sie unbekannt sind) – das ist besser als ein leerer Rahmen.