Inhaltsverzeichnis
17.11.2025
12.11.2025
09.11.2025
07.11.2025
29.10.2025
28.10.2025
22.10.2025
18.10.2025
11.10.2025
06.10.2025
04.10.2025
26.09.2025
18.09.2025
10.09.2025
27.08.2025
23.08.2025
16.08.2025
11.08.2025
09.08.2025
01.08.2025
29.07.2025
21.07.2025
20.07.2025
15.07.2025
16.06.2025
16.06.2025
15.06.2025
13.06.2025
11.06.2025
10.06.2025
09.06.2025
03.06.2025
04.05.2025
02.05.2025
30.04.2025
29.04.2025
26.04.2025
25.04.2025
24.04.2025
23.04.2025
22.04.2025
Wie wir bei 4WT komplexe Qualitätssicherungsprozesse erfolgreich in ein Kundenprojekt integrierten.
Ein Erfahrungsbericht aus der Unternehmensberatungspraxis von 4WT
Aufgabe
Ein sehr bekannter deutscher Klient unseres Softwareingenieur- und Unternehmensberatungsbüros 4WT sah sich mit signifikanten Qualitätsproblemen in seinen Softwareprodukten konfrontiert. Fehler wurden häufig erst in der Produktionsumgebung entdeckt, die Entwicklungsabteilung agierte ohne eine systematische Teststrategie, und die Organisation betrachtete Qualitätssicherung (QS) als nachgelagertes Anhängsel. Die Geschäftsführung beauftragte uns daher mit der umfassenden Analyse, Konzeption und Einführung eines unternehmensweiten Qualitätssicherungssystems. Unsere Aufgabe umfasste den Aufbau einer automatisierten Testarchitektur, die nahtlos mit einer modernen Atlassian-Infrastruktur (Jira + Xray) harmoniert, personelle und strukturelle Defizite kompensiert sowie entwicklungsbegleitend, reproduzierbar und wirtschaftlich tragfähig ist. Bei der Komplexität dieses Auftrages zogen wir unseren internationalen Partner, die Beratungsgesellschaft NUCIDA Group hinzu. Die Atlassian-Umgebung wurde im Zuge dieses Projekts von unseren genannten Partner vollständig konzipiert, installiert und in die bestehenden Unternehmensprozesse integriert.Ausgangslage beim Klienten
Das Unternehmen verfügte über drei etablierte IT-Umgebungen:- Entwicklungsumgebung: Für interne Softwareentwickler.
- Referenzumgebung: Ein dem Staging-Bereich ähnelnder Akzeptanztestbereich.
- Produktionsumgebung: Für den operativen Live-Betrieb.
Zusätzlich bestand eine gravierende personelle Fehlbesetzung im QS-Bereich. Die QS-Teams setzten sich überwiegend aus Studenten, Quereinsteigern oder Praktikanten zusammen, denen es an Softwareentwicklungskenntnissen sowie an technischem und fachlichem Verständnis mangelte. Aus technischer Sicht resultierten daraus folgende zentrale Defizite:
- Mangelndes Verständnis für Softwarearchitektur: Teammitglieder konnten Abhängigkeiten, Seiteneffekte oder Modulstrukturen nicht erfassen, was zu fundamental unzureichenden Testfällen führte.
- Fehlende Erfahrung mit APIs und Datenflüssen: Tests auf Daten- oder Integrationsebene waren undurchführbar, da die System- und Kommunikationsstruktur unbekannt war.
- Unkenntnis fachlicher Workflows: Ohne Verständnis für die Geschäftslogik konnten keine fachlich sinnvollen Testsequenzen erstellt oder deren Ergebnisse bewertet werden.
- Defizite bei Infrastruktur und Deployment: Probleme, die sich aus Systemkonfiguration, Berechtigungen oder Netzwerkanbindungen ergaben, wurden weder erkannt noch korrekt eingeordnet.
- Kein Bewusstsein für technische Sonderfälle: Komplexe Sachverhalte wie Speicherlecks, Thread-Konflikte, Race Conditions, asynchrone Verarbeitungsprobleme oder Validierungslogik blieben unberücksichtigt.
- Unfähigkeit, negative Tests zu schreiben: Statt einer systematischen Überprüfung auf Fehlverhalten wurden ausschließlich "Happy Path"-Tests durchgeführt.
Gerade auf der Leitungsebene bestand kaum Verständnis für den tatsächlichen Nutzen erfahrener Testingenieure. Dort herrschte oft die Annahme vor, dass Testen eine einfache Hilfstätigkeit sei, die jeder mit einem Grundverständnis für Benutzeroberflächen ausüben könne. Diese Sichtweise erforderte erhebliche Aufklärungsarbeit, insbesondere gegenüber Entscheidungsträgern ohne IT-Hintergrund.
Dabei ist die Realität anders: Fehlerhafte Tests oder unentdeckte Risiken können in produktiven Systemen zu massiven Folgekosten, Reputationsverlust und Compliance-Problemen führen. Die Investition in qualifizierte Testingenieure wirkt sich hingegen direkt auf die betriebliche Stabilität und wirtschaftliche Planbarkeit aus.
Unser methodischer Ansatz
Unsere Lösung basierte auf einer Integration von vier Kernkomponenten:- Verpflichtende Unit-Tests: Implementierung von Unit-Tests mit JUnit für alle Entwickler.
- Automatisierte End-to-End-Tests: Einführung von automatisierten End-to-End-Tests mittels Selenium und WebDriver in der Referenzumgebung.
- Integriertes Reporting: Zentralisiertes Test-Reporting via Jira/Xray als zentrales Kontrollzentrum.
- Professionalisierung der Testteams: Besetzung der Testteams mit erfahrenen Testingenieuren, die über Entwicklungs- oder Architekturhintergrund verfügen.
- Systemische Fehlererkennung: Sie erkennen systemische Fehler frühzeitig, bevor diese die gesamte Softwarearchitektur beeinträchtigen.
- Tiefes technisches Verständnis: Sie verstehen APIs, Datenflüsse und Zustandsübergänge umfassend.
- Abbildung fachlicher Anforderungen: Sie können komplexe fachliche Anforderungen präzise in technische Testfälle überführen.
- Effizienzsteigerung: Sie minimieren Korrekturschleifen, aufwendige Nachtests und Eskalationen.
Ein erfahrener Testingenieur kann den gesamten Systemkontext erfassen, versteht die Funktionsweise eines Software-Stacks und identifiziert Konstellationen, die für Regressionen oder Seiteneffekte anfällig sind.
Sie stellen nicht nur einen Fehler formal fest, sondern untersuchen die Ursache und geben der Entwicklung wichtige Hinweise, damit diese sofort beginnen können den Bug zu beheben anstatt stundenlang versuchen, den Fehler nachzustellen.
siehe auch Blog: Software-Ingenieur vs. Software-Testingenieur in der Qualitätssicherung – Zwei Disziplinen, ein Anspruch auf Exzellenz
Der Erklärungsaufwand gegenüber nicht-technischen Führungsebenen bleibt dabei hoch – oft ist Überzeugungsarbeit erforderlich, um das „Warum“ hinter den implementierten Maßnahmen zu vermitteln.
Denn genau hier liegt das größere Problem: nicht primär in der Technik, sondern in der menschlichen Denkweise. Die Vorstellung, dass Qualitätssicherung anfänglich Investitionen erfordert, aber langfristig Kosten spart, ist vielen Führungskräften fremd. Sie sehen in QS häufig eine lästige Pflicht oder gar eine reine Kostenstelle, nicht aber eine strategische Investition.
Gerade hier liegt die Rolle des Ingenieurbüros 4WT, diese Sichtweise zu korrigieren und aufzuzeigen, dass nachhaltige Qualität den wirtschaftlichen Erfolg sichert.
Architektur der automatisierten Tests (aus Ingenieursperspektive)
Der vollständige Aufbau unserer automatisierten Testarchitektur basiert auf der Methodik des Keyword-Driven Testings (KDT) in Kombination mit einem eigens entwickelten Java-Framework.
Dieses Framework bildet alle relevanten Schritte über Selenium und WebDriver ab.Zunächst wurden gemeinsam mit den Fachabteilungen und Systemverantwortlichen sämtliche relevanten Use Cases und Geschäftsprozesse identifiziert. Diese wurden in eigenständige Testszenarien überführt, welche wiederum in atomare Testeinheiten zerlegt wurden – sogenannte KDT-Kommandos.
Jedes KDT-Kommando beschreibt eine definierte Interaktion mit der Anwendung, beispielsweise „Login“, „Daten validieren“, „View öffnen“ oder „Datensatz speichern“. Diese Kommandos enthalten Parameter, Soll-Ist-Vergleiche, Bedingungen und Validierungsregeln. Sie wurden in einem Java-basierten Testframework implementiert und greifen über WebDriver auf die jeweiligen DOM-Elemente der Webanwendung im virtuellen Browser zu.
Die Testszenarien wurden anschließend vollständig in Jira/Xray abgebildet. Dort wurden für jeden Testfall individuelle Steps angelegt – jeder Step entspricht einem KDT-Kommando.
Die zugehörigen Parameter, Validierungsregeln und Reports werden direkt im jeweiligen Step hinterlegt.
Zur Ausführung wird über Jenkins ein Build-Job gestartet, der unser Java-Framework aus dem Git-Repository auscheckt, kompiliert und anschließend ausführt. Dem Framework wird dabei der "testExecutionKey" aus Xray übergeben. Über die Xray-REST-API wird die zugehörige Testdefinition ausgelesen, die enthaltenen Steps (KDT-Kommandos) mitsamt ihren Parametern verarbeitet und ausgeführt.
Nach jeder Aktion wird das Ergebnis – inklusive Screenshot und Logauszug – zurück an Xray übermittelt. Der Status jedes Steps ist somit direkt in Jira dokumentiert.
Alle Tests können regelmäßig oder ereignisgesteuert ablaufen, beispielsweise bei einem neuen Deployment oder einem Pull Request.
Ein entscheidender Vorteil dieses Ansatzes liegt in der vollständigen Trennung von Testlogik und Testdefinition:
- Neue oder geänderte Anforderungen können ohne Anpassung des Java-Codes umgesetzt werden.
- Es ist keine Kompilierung oder kein Deployment erforderlich; Änderungen erfolgen direkt in Xray.
- Testdesigner (auch ohne Entwicklerrolle) können Testszenarien definieren und anpassen.
- Ergebnisse sind sofort sichtbar, und Rückmeldeschleifen werden extrem verkürzt.
Wiederherstellbarkeit der Testumgebung
Ein oft übersehener, aber kritischer Bestandteil automatisierter Tests ist die konsequente Wiederherstellbarkeit der Testumgebung. Da jeder Testlauf produktionsnahe Daten, Konfigurationen und Berechtigungen verändert, muss nach jedem Durchlauf ein definierter Ausgangszustand wiederhergestellt werden.Wir entwickelten hierfür ein automatisiertes Reset-System, das auf Knopfdruck folgende Schritte ausführt:
- Neuinitialisierung relevanter Testdaten aus vordefinierten Templates.
- Zurücksetzen von Konfigurationen basierend auf definierten Policies.
- Rückführung von Berechtigungsstrukturen, Rollenzuweisungen und Systemparametern auf ihre Anfangswerte.
- Tests reproduzierbar bleiben.
- Keine Seiteneffekte aus vorherigen Testläufen bestehen.
- Die Stabilität und Vergleichbarkeit der Testergebnisse gewährleistet ist.
Transparenz für die Geschäftsführung
Ein weiterer entscheidender Vorteil: Durch die Integration der Tests in Jira/Xray können für jede Ebene des Unternehmens maßgeschneiderte Reports und Dashboards erstellt werden. Diese Berichte aktualisieren sich automatisch auf Basis der Testergebnisse:- Entwickler sehen sofort, welche Funktionalitäten fehlschlagen und erhalten technische Details.
- Fachabteilungen erhalten visuelle Statusanzeigen zu fachlichen Workflows und Use Cases.
- Geschäftsführung und CEO haben jederzeit Zugriff auf aggregierte Qualitätskennzahlen, Trends und Risikoanalysen – ohne selbst ins Detail gehen zu müssen.
Fazit
Qualitätssicherung ist nicht primär eine Frage der eingesetzten Tools, sondern vielmehr des Reifegrades, der Haltung und des systemischen Denkens innerhalb einer Organisation. Unser Projekt demonstriert: Wenn technisches Know-how, organisatorische Klarheit und konsequente Umsetzung zusammenkommen, lässt sich eine testgetriebene Unternehmenskultur etablieren – effizient, messbar und wirtschaftlich tragfähig.Video-Zusammenfassung dieser Seite:
Weiterführende Links
- Exzellenz in Softwarequalität:
Umfassendes Qualitätsmanagement, QS und Testing mit Ihrem Partner 4WT, dem deutschen Java-Enterprise-Software-Ingenieurbüro in Thailand
Praxiserfahrung – 4WT, Ihr deutsches Software-Ingenieurbüro in Thailand
- Deutsches Software-Ingenieurbüro in Bangkok mit Spezialisierung auf Testengineering & Qualitätssicherung
