Antwort: Continuous Delivery bedeutet, dass Software jederzeit technisch bereit für den produktiven Einsatz ist, aber eine manuelle Freigabe erforderlich ist. Continuous Deployment geht einen Schritt weiter und automatisiert den gesamten Prozess bis zur produktiven Nutzung, wenn alle Quality Gates erfüllt sind. Delivery: “bereit zum Deployment”, Deployment: “automatisch im Einsatz”.

Antwort: Eine umfassende Review-Checkliste sollte enthalten: Architekturkonformität (Entscheidungen, Patterns), Sicherheitsüberprüfung (Input-Validierung, Authentifizierung), Fehlerbehandlung (Exception Handling, Logging), Testabdeckung (Unit-Tests, Integrationstests), Naming Conventions, Code-Komplexität (Cyclomatic Complexity), Performance-Aspekte und Dokumentation (Comments, API-Doc).

Antwort: Die Audit-Vorbereitung umfasst: Geltungsbereich definieren (Prozesse, Systeme, Zeiträume), Nachweise sammeln (Dokumentation, Testergebnisse, Protokolle), Policies und ADRs bereitstellen, Stichprobenplan erstellen, Mitarbeiter schulen, Maßnahmenplan für identifizierte Mängel entwickeln und Audit-Trail sicherstellen.

Antwort: Die statische Codeanalyse dient der automatisierten Erkennung von stilistischen, strukturellen und sicherheitsrelevanten Verstößen ohne Code-Ausführung. Sie setzt Quality Gates, überwacht Technical Debt, prüft Compliance-Regeln und liefert Metriken wie Cyclomatic Complexity. Tools wie SonarQube integrieren sich in CI/CD-Pipelines und verhindern die Integration von qualitativ minderwertigem Code.

Antwort: Test-Wirksamkeit wird durch mehrere Metriken gemessen: Mutation Score (wie gut Tests Code-Mutationen erkennen), Flaky Rate (Stabilität der Tests), Defekterkennung vor Release, Test Coverage als Trend (nicht als absolute Zahl), Test-Ausführungszeit und Regressionstest-Erfolgsrate. Hohe Wirksamkeit zeigt sich durch frühe Fehlererkennung und geringe Produktionsfehler.

Antwort: Quality Gates sind automatisierte Entscheidungspunkte in CI/CD-Pipelines, die den Fortschritt basierend auf definierten Qualitätskriterien erlauben oder blockieren. Implementierung erfolgt durch Schwellenwerte für Metriken (Coverage < 80% = Block), Security-Scans, Performance-Tests und Code-Review-Status. Gates werden in Pipeline-Tools wie Jenkins, GitLab CI oder GitHub Actions konfiguriert.

Antwort: Die Testpyramide beschreibt die ideale Verteilung von Testarten: Unit-Tests (70%) - schnell, isoliert, viele; Integration-Tests (20%) - mittel, Komponenten-Interaktion; E2E-Tests (10%) - langsam, gesamtes System. Bedeutung: schnelles Feedback durch viele Unit-Tests, Cost-Effizienz durch weniger teure E2E-Tests, bessere Fehlerisolierung und stabile Test-Suite.

Antwort: Mutation Testing ist eine Technik zur Bewertung der Testqualität. Dabei werden kleine Änderungen (Mutationen) im Code vorgenommen und geprüft, ob die Tests diese erkennen. Einsatz bei kritischen Systemen, zur Test-Optimierung und für Quality Gates. Hoher Mutation Score (>80%) deutet auf gute Testabdeckung hin. Tools wie PIT (Java) oder Stryker (JavaScript) automatisieren diesen Prozess.

Antwort: Pair Programming bietet Echtzeit-Review (Fehler werden sofort erkannt), Wissenstransfer (Erfahrungsaustausch zwischen Teammitgliedern), geringere Defektrate (zwei Paar Augen sehen mehr), bessere Architekturentscheidungen (Diskussion im Team) und kontinuierliches Lernen. Besonders wertvoll für komplexe Probleme, Onboarding neuer Mitarbeiter und kritische Code-Bereiche.

Antwort: Ein effektiver Bugtracking-Prozess umfasst: strukturierte Erfassung (Reproduktionsschritte, Umgebung, Logs), Priorisierung nach Severity und Priority, Zuweisung an verantwortliche Entwickler, Status-Tracking (New → In Progress → Fixed → Tested → Closed), Verknüpfung mit Commits und Releases, Root-Cause-Analyse und Metriken wie MTTR und Defektdichte.

Antwort: Definition of Ready (DoR) definiert Kriterien, die eine User Story erfüllen muss, bevor sie in einen Sprint aufgenommen wird (klare Anforderungen, Akzeptanzkriterien, technisch umsetzbar). Definition of Done (DoD) beschreibt Abschlusskriterien für eine Aufgabe (Code Review bestanden, Tests grün, Dokumentation aktualisiert, Deploy-fähig). Beide stellen Qualitätssicherungs-Mechanismen im agilen Prozess dar.

Antwort: Git Flow (feature-Branches, develop, release, master) für strukturierte Releases mit umfangreichen Tests. GitHub Flow (feature-Branch → master → deploy) für schnelle Deployment-Zyklen. Trunk-Based Development für extreme Continuous Integration mit minimalen Branches. Wahl hängt ab von Release-Frequenz, Team-Größe, Compliance-Anforderungen und Risikotoleranz.

Antwort: Security-Integration erfolgt durch: SAST (Static Application Security Testing) im Build, Dependency-Scanning für bekannte Vulnerabilities, DAST (Dynamic Application Security Testing) in Staging, Container-Scanning, Secret-Management, Compliance-Checks und Security-Gates. Tools wie OWASP ZAP, SonarQube Security oder Trivy werden in Pipeline-Stufen integriert.

Antwort: Feature Flags sind Konfigurationsschalter, die Funktionalitäten zur Laufzeit ein- oder ausschalten. Sie unterstützen Qualitätssicherung durch schrittweise Freischaltung (Canary Releases), A/B-Testing, schnelles Deaktivieren bei Problemen, parallele Entwicklung und risikominimierte Deployments. Implementierung über Config-Server, Feature-Toggle-Tools oder einfache Konfigurationsdateien.

Antwort: Canary Deployment rollt neue Version schrittweise an kleine Nutzergruppen aus und überwacht Metriken. Blue-Green Deployment betreibt zwei identische Produktionsumgebungen; Traffic wird komplett auf neue Umgebung (Green) umgeschaltet. Beide minimieren Deployment-Risiken, ermöglichen schnelles Rollback und liefern frühes Feedback. Wahl hängt von Infrastruktur und Risikostrategie ab.

Antwort: Die DORA-Metriken umfassen: Deployment Frequency (wie oft wird deployed), Lead Time for Changes (Zeit von Commit zu Deployment), Mean Time To Recovery (MTTR) (Zeit zur Wiederherstellung nach Ausfall) und Change Failure Rate (Anteil fehlerhafter Deployments). Hohe Performer zeigen häufige Deployments, kurze Lead Times, schnelle Recovery und niedrige Failure Rates.

Antwort: Technical Debt beschreibt die zukünftigen Kosten für suboptimale technische Entscheidungen. Management durch Identifikation (Code-Analyse, Team-Feedback), Priorisierung (Impact vs. Effort), Tracking (Technical Debt Ratio, SonarQube), Repayment-Strategie (regelmäßige Refactoring-Sprints) und Prävention (Code Reviews, Architektur-Entscheidungen). Ziel: Bewusste Entscheidungen statt unkontrollierter Verschlechterung.

Antwort: Nicht-funktionale Tests umfassen: Performance-Tests (Load, Stress, Spike), Security-Tests (Penetration, Vulnerability), Usability-Tests (User Experience, Accessibility), Verfügbarkeitstests (High Availability, Failover), Skalierbarkeitstests (Horizontal/Vertical Scaling) und Compliance-Tests (DSGVO, ISO-Normen). Diese Tests werden oft in spezialisierten Umgebungen und mit dedizierten Tools durchgeführt.

Antwort: ADRs dokumentieren wichtige Architekturentscheidungen mit Kontext, Entscheidung, Begründung und Konsequenzen. Sie sind wichtig für Nachvollziehbarkeit, Wissenstransfer, Consistency und Onboarding. ADRs werden versioniert, oft in Markdown-Format gespeichert und als Teil der Projekt-Dokumentation behandelt. Sie unterstützen Architektur-Governance und Entscheidungsfindung.

Antwort: Umgebungstrennung erfolgt durch physische Trennung (verschiedene Server/Cluster), logische Trennung (Datenbank-Schemas, Konfigurationen), Netzwerk-Trennung (Firewalls, VPNs), Daten-Trennung (anonymisierte Testdaten) und Zugriffskontrolle (RBAC). Ziel: Sicherheit der Produktionsdaten, stabile Tests und parallele Entwicklung. Container-Technologien (Docker, Kubernetes) vereinfachen diese Trennung.

Antwort: Contract Testing überprüft die Kompatibilität zwischen Microservices durch definierte “Contracts” (API-Spezifikationen). Verwendung bei Microservice-Architekturen, um Integrationstests zu beschleunigen, Breaking Changes früh zu erkennen und parallele Entwicklung zu ermöglichen. Tools wie Pact oder Spring Cloud Contract automatisieren diesen Prozess und integrieren ihn in CI/CD-Pipelines.

Antwort: Dokumentations-Qualität wird sichergestellt durch Versionierung (im Repository), Automatisierung (Doc-Generation aus Code), Review-Prozesse (Technical Writer Review), Templates (standardisierte Strukturen), Verknüpfung mit Code (API-Doc), Regelmäßige Updates (als Teil von DoD) und Benutzer-Feedback. Tools wie Swagger/OpenAPI, Javadoc oder MkDocs unterstützen diesen Prozess.

Antwort: Smoke Tests sind einfache Tests, die die grundlegende Funktionsfähigkeit einer Anwendung nach Deployment überprüfen. Sie werden nach jedem Deployment ausgeführt, um kritische Fehler früh zu erkennen. Typische Smoke Tests: Login-Funktion, Datenbank-Verbindung, API-Endpunkte, externe Services. Sie sind schnell (wenige Minuten) und geben ein Go/No-Go Signal für weitere Tests.

Antwort: Testdatenverwaltung umfasst Test-Data-Factorys (programmatische Erzeugung), Containerisierung (Docker mit Testdaten), Datenbank-Migrationen (Flyway, Liquibase), Mocking für externe Dependencies, Data-Cleanup zwischen Tests und Versionierung von Testdaten. Ziel: reproduzierbare Tests, Performance und Isolation der Testumgebungen.

Antwort: Frage: “Beschreiben Sie einen vollständigen Qualitätssicherungsprozess für ein neues Web-Projekt.” Antwortstruktur: 1. Präventive Maßnahmen (Coding Standards, Architecture Guidelines), 2. CI/CD-Pipeline (Build → Test → Analyze → Deploy), 3. Code Reviews (Checkliste, Vier-Augen-Prinzip), 4. Teststrategie (Unit, Integration, E2E), 5. Quality Gates (Metriken, Security), 6. Monitoring (Production Metrics), 7. Continuous Improvement (Retrospectives, Metrics). Diese Struktur zeigt systematisches Vorgehen und QS-Kompetenz.