QA, Testing & Observability

Manuelles Regressionstesting ist der teuerste Weg, die Entwicklung zu verlangsamen. Ein QA-Team, das vor jedem Release 3 Tage die gleichen Szenarien durchklickt, ist ein Bottleneck. Testautomatisierung verlagert die Regression in die CI-Pipeline — sie läuft bei jedem Commit, Ergebnis in Minuten.

Testpyramide in der Praxis: Unit Tests (70 %) — schnell, isoliert, Hunderte pro Sekunde. Integrationstests (20 %) — API-Verträge, Datenbankoperationen, Message Broker. E2E-Tests (10 %) — kritische Business-Flows über den gesamten Stack. Das Verhältnis ist kein Dogma, sondern Richtung — mehr Unit, weniger E2E.

E2E-Framework: Playwright für Web (Multi-Browser, Auto-Waiting, Network Interception). Detox für React Native, XCTest/Espresso für nativ. Page Object Model für Wartbarkeit. Visual Regression Testing (Percy, Chromatic) für UI-Änderungen.

CI-Integration: Tests laufen in GitHub Actions / GitLab CI bei jedem Push. Parallelisierung für Geschwindigkeit — 500 Tests in 5 Minuten, nicht 45. Flaky-Test-Erkennung und Quarantäne — ein instabiler Test blockiert die Pipeline nicht, generiert aber einen Alert. Testbericht mit Coverage-Trends.

Contract Testing: Pact für API-Verträge zwischen Frontend und Backend, zwischen Microservices. Der Provider verifiziert den Vertrag in seiner eigenen CI — ein Breaking Change wird vor dem Merge erkannt, nicht in der Integration. Consumer-Driven Contracts für unabhängige Teams.

Monitoring sagt Ihnen, DASS ein Problem vorliegt. Observability sagt Ihnen WARUM. Mit Monitoring wissen Sie, dass die API langsam ist. Mit Observability sehen Sie den konkreten Trace: Der Request ging durch 6 Services, der Bottleneck ist eine Query im Order-Service, die 8s dauert wegen eines fehlenden Index. Fix in 5 Minuten statt 5 Stunden.

Drei Säulen: Metriken (Prometheus) — numerische Zeitreihen, Alerting auf SLOs. Logs (Loki, Elasticsearch) — strukturierte Events mit Kontext. Traces (Jaeger, Tempo) — der Weg eines Requests durch ein verteiltes System. Drei Säulen verbunden — vom Alert klicken Sie zum relevanten Trace, vom Trace zu den Logs.

OpenTelemetry als Standard: Vendor-neutrale Instrumentierung. Ein SDK, Export in jedes Backend (Grafana Stack, Datadog, New Relic). Auto-Instrumentierung für populäre Frameworks (.NET, Java, Python, Node.js). Custom Spans für Geschäftslogik — Sie sehen nicht nur HTTP-Requests, sondern auch „Bestellverarbeitung dauerte 3,2s”.

Dashboards und Alerting: Grafana-Dashboards für SRE (SLO Burn Rate, Error Budget), für das Dev-Team (Deployment-Frequenz, Lead Time, MTTR), für Business (Conversions, Umsatz, aktive Nutzer). Alerting auf Symptome (SLO-Verletzung), nicht auf Ursachen (CPU > 80 %). PagerDuty/OpsGenie-Integration mit Eskalation.

Kosten unter Kontrolle: Observability-Daten wachsen schnell. Sampling-Strategien (Head-Based, Tail-Based) für Traces. Log-Levels und Aufbewahrungsrichtlinien. Metriken mit angemessener Granularität. Typischerweise 60–80 % Einsparung gegenüber „alles loggen”.

Ein KI-Modell ohne Evaluierungen ist eine Blackbox in der Produktion. Funktioniert es? Vielleicht. Besser als letzte Woche? Wissen Sie nicht. Sicher? Sie hoffen es. KI-Evaluierungen führen Messbarkeit ein — Sie wissen genau, wie das Modell performt, wo es versagt und wann es degradiert.

LLM-Evaluierungen: Precision, Recall, Faithfulness (Halluzinationsrate), Relevanz, Safety Scoring. Evaluierungsdatensätze spezifisch für Ihre Domäne — keine generischen Benchmarks, sondern echte Anfragen Ihrer Nutzer. Automatisierte Evaluierungen via LLM-as-Judge (GPT-4 bewertet Produktionsmodell-Antworten) und Human-in-the-Loop.

Drift-Erkennung: Modellqualität verändert sich über die Zeit — die Verteilung der Eingabedaten verschiebt sich, Nutzerverhalten ändert sich, die Welt ändert sich. Monitoring der Schlüsselmetriken mit Alerting: Wenn die Precision um 5 % fällt, erhalten Sie einen Alert. Sliding-Window-Analyse zur Erkennung gradueller Degradation.

A/B-Modelltests: Neues Modell vs. bestehendes. Traffic Split 50/50, Messung von Business-Metriken (Conversion, Nutzerzufriedenheit, Task Completion) und technischen Metriken (Latenz, Kosten pro Request). Statistische Signifikanz vor einer Entscheidung — nicht „scheint besser”, sondern „ist besser mit p < 0,05”.

Evaluierungspipeline: Automatisierte Evaluierungen in CI/CD — ein neues Modell muss die Eval Suite bestehen, bevor es in Produktion deployed wird. Quality Gate: Wenn Precision < 0,85 oder Safety Score < 0,95, wird das Deploy gestoppt. Regressionstesting — ein neues Modell darf in keiner Kategorie schlechter sein.

Tooling: LangSmith, Ragas, Custom Eval Frameworks. Eval-Datensätze versioniert in Git. Ergebnisse in Grafana-Dashboards neben Infrastrukturmetriken. Ein Blick auf die Gesundheit des gesamten KI-Systems.

Kunden sind das schlechteste Lasttest-Tool. Wenn Sie von einem Performance-Problem über Twitter erfahren, ist es zu spät. Lasttests decken Systemgrenzen in einer kontrollierten Umgebung auf — Sie wissen genau, wo der Bottleneck ist und wie viel Headroom Sie haben.

Testarten: Lasttest (erwarteter Traffic), Stresstest (2–3× erwartet), Spike-Test (plötzlicher Anstieg), Soak-Test (konstante Last über 24–72h für Memory Leaks und Connection-Pool-Erschöpfung). Jeder Typ deckt ein anderes Problem auf. Wir „werfen nicht einfach 1000 Nutzer drauf” — wir simulieren reale Verhaltensmuster.

k6 als primäres Tool: JavaScript-Skripte, CI/CD-Integration, Grafana-Dashboards. Skripte versioniert in Git neben dem Anwendungscode. Schwellenwerte als Code definiert — der Test schlägt fehl, wenn P95-Latenz > 200 ms oder Fehlerrate > 1 %. Verteilte Last aus mehreren Regionen für globale Anwendungen.

Profiling und Bottleneck-Analyse: Ein Lasttest ist nur der Anfang. Wichtig ist zu verstehen, WARUM das System sein Ziel nicht erreicht. APM-Profiling (Async Profiler, dotTrace), Datenbankabfrageanalyse (Slow Query Log, Execution Plans), Ressourcen-Monitoring (CPU, Speicher, Netzwerk, Disk I/O). Wir identifizieren die Top-3-Bottlenecks und beheben sie.

Baseline und Trending: Wir vergleichen jedes Release mit einer Baseline. Automatische Performance-Regressionserkennung in CI. Trend-Dashboard — P95-Latenz wächst mit jedem Release um 5 ms, in 6 Monaten wird es ein Problem. Besser jetzt angehen.

Capacity Planning: Aus Lasttests extrapolieren wir: Wie viele Nutzer können wir auf der aktuellen Infrastruktur bedienen? Was kostet die Skalierung auf 2×? 10×? Datengetriebene Infrastrukturentscheidungen, keine Schätzungen.

Incidents passieren. Entscheidend ist, was Sie danach tun. Organisationen ohne Incident-Response-Prozess improvisieren unter Stress. Ergebnis: lange MTTR, schlechte Kommunikation, wiederholte Fehler. Wir bauen Prozesse, die auch am Sonntagabend funktionieren.

Severity-Framework: SEV1 (Business Impact, Kunden betroffen) → sofortige Eskalation, War Room, 15-Minuten-Status-Updates. SEV2 (degradierte Performance) → On-Call reagiert innerhalb von 30 Min. SEV3 (geringfügiges Problem) → wird während der Geschäftszeiten gelöst. SEV4 (kosmetisch) → Backlog. Klare Regeln, keine Debatten über Severity während eines Incidents.

Runbooks: Schritt-für-Schritt-Anleitungen für die Top 15–20 Incidents. „API gibt 500 zurück” → Health Endpoints prüfen → Datenbankverbindung prüfen → letzte Deployments prüfen → Rollback bei Bedarf. Ein Runbook ist kein Aufsatz — es ist eine Checkliste. Wird nach jedem Post-Mortem aktualisiert.

On-Call: Rotation (typischerweise wöchentlich), primärer + sekundärer On-Call. PagerDuty/OpsGenie mit intelligentem Routing. Eskalationsmatrix — wenn der Primäre nicht innerhalb von 5 Minuten reagiert, wird der Sekundäre benachrichtigt. Vergütung für On-Call — Menschen, die nachts aufwachen, verdienen Anerkennung.

Blameless Post-Mortem: Innerhalb von 48 Stunden nach jedem SEV1/SEV2. Incident-Timeline, Root Cause, beitragende Faktoren, Action Items mit Verantwortlichen und Fristen. Kein „Wer ist schuld?” — stattdessen „Was ändern wir, damit das nicht wieder passiert?”. Learnings werden über die Organisation geteilt. Post-Mortem-Datenbank als Knowledge Base.

Chaos Engineering: Kontrollierte Fehlerinjektion in Produktion. Instanz herunterfahren, Latenz erhöhen, Netzwerkpartition simulieren. Verifizierung, dass Failover- und Degradation-Mechanismen funktionieren. Netflix-Style Game Days quartalsweise.

Ein Quality Gate ist ein automatischer Wächter. Code, der den Qualitätsstandard nicht erfüllt, kommt nicht in Produktion. Keine Ausnahmen, kein „Ich deploye es und fixe es später”. Das Gate ist unbarmherzig, aber fair — die Regeln sind klar und vorab bekannt.

Statische Analyse: SonarQube / SonarCloud für Code-Qualität (Code Smells, Duplizierung, Komplexität), Sicherheit (OWASP Top 10, CWE), Coverage. Qualitätsprofile pro Projekt — unterschiedliche Standards für neuen Code vs. Legacy. Neuer Code muss Coverage > 80 % haben, null kritische Issues. Schrittweise Verschärfung für bestehende Codebases.

Security Gates: Dependency Scanning (Snyk, Dependabot) — bekannte CVEs in Abhängigkeiten blockieren das Deploy. Container Image Scanning (Trivy) — verwundbare Base Images. SAST (Static Application Security Testing) integriert in CI. Secrets Detection (GitLeaks) — keine Credentials im Code.

Performance Gates: Automatisierter Lasttest in CI (Teilmenge, 5 Minuten). Wenn P95-Latenz um >10 % gegenüber der Baseline steigt, wird das Deploy gestoppt. Bundle-Size-Check für Frontend — eine neue Abhängigkeit darf ohne explizites Review nicht mehr als 50 KB hinzufügen. Lighthouse Score für Web-Performance.

Deployment Gates: Canary Deployment mit automatischer Evaluierung. Metriken (Fehlerrate, Latenz) verglichen mit Baseline. Wenn Degradation > Schwellwert, automatischer Rollback. Progressive Delivery — Gate bei jedem Schritt (5 % → 25 % → 50 % → 100 %).

Kultur: Quality Gates funktionieren nur, wenn das Team sie annimmt. Es ist kein Management-Tool zur Kontrolle — es ist ein Sicherheitsnetz für Entwickler. Das Gate soll fangen, was Code Review übersieht. False-Positive-Rate unter 5 % — sonst fängt das Team an, Gates zu ignorieren.