Qualitätssicherung und Release Management in der agilen Softwareentwicklung

In der agilen Softwareentwicklung stehen Unternehmen vor der Herausforderung, kontinuierlich neue Funktionen und Verbesserungen in ihre Anwendungen zu integrieren, ohne dabei die Stabilität und Qualität der Software zu gefährden. Besonders anspruchsvoll ist dies, wenn die Software für mehrere Kunden bereitgestellt wird, die unterschiedliche Anforderungen und Update-Zyklen haben.

Dieser Artikel beschreibt ein praxiserprobtes, ganzheitliches Konzept zur Organisation der Qualitätssicherung (QA) und des Release Managements. Der Fokus liegt auf drei zentralen Bereichen:

1. Organisatorische Abläufe: Effektive Zusammenarbeit zwischen Entwicklung, QA und Produktmanagement.
2. Test-Setup: Strukturierte Teststrategie mit Automatisierung und manuellen Tests.
3. Release-Management: Sicherstellung stabiler und transparenter Releases mit Versionierung, Kundeneinbindung und Rollback-Optionen.

Dieses Konzept ist flexibel und kann auf verschiedene Softwareprojekte und Unternehmensgrößen angepasst werden.

Organisatorische Abläufe

Teamstruktur und Rollen

Ein effektives QA- und Release-Management erfordert klare Rollenverteilungen und eine enge Zusammenarbeit zwischen den beteiligten Teams:

• QA-Team: Bestehend aus 3-4 Testexperten, abhängig von Umfang und Größe des Softwareproduktes. Verantwortlich für die Konzeption und Umsetzung von automatisierten und manuellen Tests sowie die Sicherstellung der Release-Qualität.
• Entwicklungsteams (Squads): Arbeiten agil an der Implementierung neuer Features und Bugfixes und integrieren ihre Änderungen fortlaufend in die Testversion.
• Product Owner (PO): Definiert Akzeptanzkriterien, priorisiert Anforderungen und plant die Releases in Abstimmung mit den Kunden.

Arbeitsphasen

Phase 1: Entwicklung und Basic-QA

• Entwickler integrieren neue Funktionen und Bugfixes in den Hauptzweig des Repositories.
• Automatisierte Tests (Linting, Unit-Tests, Integrationstests, Security-Scans) stellen die grundlegende Qualität sicher (Basic-QA).

Phase 2: High-QA und Staging

• Die QA-Experten prüfen die aktuelle Version in einer Staging-Umgebung.
• Durchführung von End-to-End-Tests, Regressionstests und Tests für kundenspezifische Konfigurationen.

Phase 3: Kundenakzeptanz

• Bereitstellung der High-QA-Version in einer kundenspezifischen Testumgebung.
• Die Kunden prüfen die Version und geben Feedback.

Phase 4: Produktivsetzung

• Nach Freigabe erfolgt das geplante Release.
• Monitoring der produktiven Umgebung, um mögliche Fehler frühzeitig zu erkennen.

Kommunikation

• Tägliche Standups: Abstimmung zwischen Entwicklung, QA und Produktmanagement.
• Wöchentliche Statusmeetings: Fortschrittskontrolle und Identifikation von Engpässen.
• Retrospektiven: Analyse vergangener Releases zur kontinuierlichen Prozessverbesserung.

Parallel laufende Versionen

Wenn verschiedene Kunden unterschiedliche Versionen verwenden, sind folgende Ansätze hilfreich:

• Feature-Toggles: Ermöglichen die Aktivierung oder Deaktivierung spezifischer Funktionen pro Kunde.
• Separate Staging-Umgebungen: Kunden erhalten eigene Testinstanzen, die den Produktionsumgebungen entsprechen.
• Versionsverwaltung: Dokumentation der eingesetzten Versionen und der spezifischen Anpassungen pro Kunde.   

Test-Setup

Teststrategie

Ein mehrstufiges Testsystem stellt sicher, dass Fehler frühzeitig erkannt werden und die Software stabil bleibt:

• Unit-Tests: Prüfen einzelne Funktionen oder Module auf korrekte Arbeitsweise. (z. B. mit pytest, JUnit). Unit-Tests sind die Basis jeder Teststrategie und helfen dabei, Fehler frühzeitig im Entwicklungsprozess zu entdecken. Dabei werden die kleinsten testbaren Einheiten der Software isoliert geprüft.
• Integrationstests: Überprüfen das Zusammenspiel von Modulen und Systemkomponenten. (z. B. mit pytest + Testcontainers). Integrationstests stellen sicher, dass die verschiedenen Komponenten einer Anwendung korrekt zusammenarbeiten. Beispielsweise wird geprüft, ob eine API-Anfrage korrekt an die Datenbank weitergeleitet und das erwartete Ergebnis zurückgegeben wird.
• End-to-End-Tests: Simulieren Nutzerinteraktionen über die gesamte Anwendung. (z. B. mit Cypress oder Selenium). Diese Tests prüfen den vollständigen Ablauf einer Benutzeraktion. Beispielsweise wird getestet, ob ein Benutzer sich registrieren, ein Produkt in den Warenkorb legen und eine Bestellung abschließen kann, ohne dass es zu Fehlern kommt.
• Performance-Tests: Belastungstests prüfen das Verhalten bei hoher Last. (z. B. mit Locust oder JMeter). Ziel ist es, die Systemleistung unter verschiedenen Lastbedingungen zu analysieren. Beispielsweise kann überprüft werden, wie das System reagiert, wenn 1.000 Benutzer gleichzeitig Bestellungen aufgeben.
• Sicherheitstests: Scannen auf Schwachstellen. (z. B. CVE-Scanner, OWASP ZAP). Sicherheitstests identifizieren potenzielle Sicherheitslücken, wie z. B. SQL-Injections, Cross-Site-Scripting oder fehlerhafte Authentifizierungssysteme.
• Regressionstests: Wiederholtes Testen der bereits implementierten Funktionen nach jeder Änderung, um sicherzustellen, dass bestehende Features weiterhin fehlerfrei funktionieren. Diese Tests sind besonders wichtig in agilen Projekten mit kontinuierlicher Entwicklung, um sicherzustellen, dass neue Funktionen keine unerwarteten Nebenwirkungen haben.

Testumgebungen

• Lokale Entwicklungsumgebung: Docker Compose zur Simulation der Systemarchitektur. Diese Umgebung erlaubt Entwickler, alle Services lokal in Containern laufen zu lassen und Integrationstests durchzuführen. Dies stellt sicher, dass Entwickler vor der Übergabe an QA bereits erste Tests in einer produktionsähnlichen Umgebung durchführen können.
• Staging-Umgebung: Cloud-gehostete Instanzen, die der Produktion möglichst gleichen. Diese Umgebung ist ideal für End-to-End-Tests, Performance-Tests und Abnahmeprüfungen durch Kunden. Eine Staging-Umgebung minimiert das Risiko, dass nicht erkannte Fehler in die Produktion gelangen.

Testdaten

• Statische Testdaten: Standardfälle zur Abdeckung der Hauptprozesse. Beispieldaten, die immer gleich sind, um die Kernprozesse zu prüfen. Beispielsweise könnten feste Benutzerkonten, Produkte oder Konfigurationsdaten verwendet werden.
• Dynamische Daten: Generierung zufälliger und Edge-Case-Daten zur Robustheitsprüfung. Zum Beispiel das Erstellen von extrem großen Datensätzen, ungültigen Eingaben oder Grenzwerten, um zu sehen, wie das System auf unvorhergesehene Eingaben reagiert.

Automatisiertes Testing

• Backend: pytest für API- und Logiktests. Diese Tests stellen sicher, dass alle Schnittstellen und Geschäftslogiken fehlerfrei arbeiten. Beispielsweise kann überprüft werden, ob eine API-Anfrage die korrekten HTTP-Statuscodes zurückgibt und die erwarteten Daten liefert.
• Frontend: Cypress zur Simulation von Nutzeraktionen. Automatisierte Browser-Tests, die typische User Journeys wie das Anmelden, das Erstellen von Einträgen oder das Durchführen einer Transaktion simulieren.
• Performance: Locust zur Simulation paralleler Nutzerströme. Das Tool ermöglicht es, die Belastung des Systems zu simulieren und Engpässe frühzeitig zu identifizieren.

Auswertung

• CI/CD-Integration: Automatische Ausführung der Tests bei jeder Änderung. Fehlerhafte Builds werden gestoppt, und Entwickler erhalten sofortiges Feedback.
• Reports: Testabdeckungsberichte, Fehlerprotokolle (z. B. Allure, SonarQube). Diese Reports liefern Einblicke in die Qualität der Software und identifizieren Bereiche, die verbessert werden müssen.
• Testmetriken: Erfassung von Metriken wie Testabdeckung, Fehlerraten und durchschnittliche Fehlerbehebungszeit zur kontinuierlichen Verbesserung der Teststrategie.   

Release-Management

Release-Prozess

Ein strukturierter Release-Prozess stellt sicher, dass neue Versionen kontrolliert und ohne Qualitätsverluste in die Produktion überführt werden:

1. Entwicklung & Basic-QA: Entwickler integrieren Änderungen in den Hauptzweig. Automatisierte Tests prüfen die Grundfunktionen und identifizieren frühe Fehler.
2. High-QA & Staging: In der Staging-Umgebung werden weiterführende manuelle und automatisierte Tests durchgeführt. Diese umfassen Integrationstests, End-to-End-Tests sowie kundenindividuelle Prüfungen.
3. Kundenfreigabe: Kunden erhalten die Möglichkeit, die High-QA-Version in ihrer eigenen Testumgebung zu prüfen. Ihr Feedback wird berücksichtigt, bevor die Version produktiv gesetzt wird.
4. Produktivsetzung: Nach der Freigabe erfolgt der produktive Rollout. Dies geschieht vorzugsweise außerhalb der Geschäftszeiten, um Auswirkungen auf Nutzer zu minimieren.
5. Post-Release-Monitoring: Nach dem Release wird das System engmaschig überwacht, um Auffälligkeiten frühzeitig zu erkennen und bei Bedarf ein schnelles Eingreifen zu ermöglichen.

Versionierung

Eine konsistente Versionierung ist essenziell, um den Überblick über eingesetzte Softwarestände zu behalten und Rollbacks zu erleichtern:

• Semantic Versioning:

• Major: Breaking Changes
• Minor: Neue Features
• Patch: Bugfixes
• Build-Nummern: Ergänzend können Build-Nummern verwendet werden, um interne Test- und Zwischenstände besser zu identifizieren.
• Changelogs: Detaillierte Änderungsprotokolle ermöglichen es, nachvollziehbar zu dokumentieren, welche Änderungen in welcher Version enthalten sind.

Parallelbetrieb

Besonders in Umgebungen mit kundenspezifischen Anpassungen ist der Parallelbetrieb unterschiedlicher Versionen notwendig:

• Docker-Container: Jede Version kann isoliert als Container bereitgestellt werden. Dies erleichtert die Pflege mehrerer Softwarestände parallel.
• Feature-Toggles: Erlauben es, neue Funktionen zunächst nur für bestimmte Kunden freizuschalten, bevor sie allgemein verfügbar gemacht werden.

Rollback-Strategien

Trotz gründlicher Tests können in der Produktion kritische Fehler auftreten. Deshalb müssen Rollback-Mechanismen vorbereitet sein:

• Backup der vorherigen Version: Vor jedem Release wird die alte Version gesichert, um im Notfall schnell zurückkehren zu können.
• Duale Betriebsstrukturen (Blue-Green-Deployment): Zwei parallele Produktionsumgebungen ermöglichen es, im Fehlerfall sofort auf die alte Version zurückzuschalten.
• Automatisierte Rollbacks: Definierte Trigger lösen ein automatisiertes Zurücksetzen auf die vorherige Version aus, wenn bestimmte Schwellenwerte (z. B. Fehlerhäufigkeit) überschritten werden.

Kommunikation

Transparente Kommunikation sorgt für Vertrauen bei Kunden und minimiert Missverständnisse:

• Release Notes: Dokumentation aller Änderungen, behobenen Fehler und neuer Funktionen.
• Kundeninformation: Frühzeitige Ankündigung von Updates, inklusive Zeitplan und erwarteter Ausfallzeiten.
• Interne Abstimmung: Klare Kommunikationswege zwischen Entwicklung, QA, Support und Produktmanagement, um im Fehlerfall schnell reagieren zu können.

Tools

• CI/CD: GitLab CI/CD, Jenkins – Automatisierung der Build-, Test- und Deployment-Prozesse.
• Monitoring: Prometheus, Grafana – Überwachung der Systemstabilität und frühzeitige Fehlererkennung.
• Versionskontrolle: Git – Nachvollziehbare Historie aller Änderungen und einfacher Wechsel zwischen Versionen.   

Fazit

Ein strukturiertes Zusammenspiel von Organisation, Teststrategie und Release-Management bildet die Grundlage für eine stabile und flexible Softwareentwicklung. Die hier dargestellten Methoden sind erprobt und lassen sich auf unterschiedlichste Projekt- und Unternehmensgrößen anpassen. Besonders in agilen Umgebungen mit variierenden Kundenanforderungen sorgt dieser Ansatz für Qualität und Planungssicherheit.