Deutsch 
Magyar 
English (UK) Wenn komplexe Architekturen die Testzeit auffressen
„Warum gibt es so viele Fehler im produktiven System, wenn wir es doch schon getestet haben?“
„Schon wieder verzögern wir uns wegen des Testens, obwohl wir den Go-Live-Termin wirklich nicht weiter schieben können.“
„Auf dem Papier haben wir einen Testprozess, aber in der Praxis funktioniert er einfach nicht…“
Kommen Ihnen diese Fragen bekannt vor?
In einer durchschnittlichen großen Unternehmens-IT-Landschaft geht es bei der Architektur heute längst nicht mehr darum, „ein monolithisches ERP und ein, zwei Schnittstellen“ zu betreiben. In den meisten Großunternehmen sind Microservices, API-first-Architekturen, Hybrid Cloud (On-Prem + AWS/Azure/GCP), dutzende Integrationen (ERP, CRM, Billing, Logistik, Identity, Mobile App, Webportal) und 3–8 parallel arbeitende Vendoren die Realität.
Dadurch wird das System nicht nur größer, sondern verändert sich qualitativ. Die Komplexität wächst netzwerkartig: Jede neue Schnittstelle vervielfacht die potenziellen Fehlerquellen.
Und was ist das Problem daran?
Grundsätzlich nichts – diese modernen Architekturen bringen zahlreiche Vorteile mit sich: schnelle geschäftliche Reaktionsfähigkeit, Flexibilität und Vendorunabhängigkeit, Skalierbarkeit und mehr Raum für Business-Experimente. Das Problem beginnt dort, wo ein neues System eingeführt oder aktualisiert wird, das Testvorgehen des Unternehmens aber – sofern überhaupt vorhanden – noch immer auf die „alte Welt“ optimiert ist. Daraus folgen fast zwangsläufig die bekannten Phänomene: Integrationsfehler in Produktion, Regressionsprobleme nach jedem Release und ein „Wenn noch Zeit bleibt“-Testen mit chronischer Unsicherheit bei Go-Live-Entscheidungen.
Bei TestIT stoßen wir häufig auf genau solche Engpässe, die den Erfolg von IT-Projekten massiv beeinflussen. Daher beleuchten wir im Folgenden ausführlicher, warum große Enterprise-IT-Projekte typischerweise ins Rutschen kommen, Fehler produzieren und teurer werden – aufgrund verborgener Schwächen im Testprozess – und in welche Richtung es sinnvoll ist, sich zu bewegen, wenn man das ändern oder zumindest die wichtigsten Fallstricke vermeiden möchte.
Die Ursachen, die zu Verzögerungen in IT-Projekten beitragen
Erster Grund: Viele Anwendungen, viele Schnittstellen, wenig Testzeit
In Enterprise-Umgebungen ist es ein sehr typisches Problem, dass mehrere Dutzend Fachanwendungen miteinander kommunizieren, potenziell Hunderte Schnittstellen (API, Batch, Message Queue) aktiv sind und gemischte Teams (Inhouse, Nearshore, Offshore, Vendoren) parallel entwickeln. Gleichzeitig werden die Release-Zyklen kürzer: Aus quartalsweisen oder halbjährlichen Releases werden an vielen Stellen monatliche oder sogar zweiwöchentliche Auslieferungen.
Laut den jüngsten Ausgaben des World Quality Report (Capgemini–Sogeti–Micro Focus) haben 60–70 % der Unternehmen das Gefühl, dass die Systemkomplexität schneller wächst als QA-Kapazität und -Kompetenz. Das zeigt sich deutlich in der Projektplanung: Der Scope wächst, Integrationen nehmen zu, Entwicklungsverzögerungen müssen irgendwie „geschluckt“ werden, aber das Go-Live-Datum bleibt fix, weil es aus geschäftlichen Gründen keinen Spielraum gibt.
Und was zieht dann in der Regel den Kürzeren? Die für das Testen vorgesehene Zeit. Aus den geplanten sechs Testwochen werden drei – auf dem Papier oft noch immer „mit demselben Scope“. Von diesen drei Wochen gehen eine für Integrations-Feuerwehr und Umgebungsprobleme drauf, eine für UAT, und im besten Fall bleibt eine Woche für Regression. Das ist in einer Architektur mit mehr als 100 Schnittstellen offensichtlich zu wenig. Kein Wunder, dass laut Gartner- und Forrester-Analysen 60–80 % der Fehler in Enterprise-Umgebungen Integrations- und Regressionsfehler sind: Die Probleme liegen nicht primär in den einzelnen Modulen, sondern in deren Zusammenspiel.
Zweiter Grund: Wir erwarten Wissen vom Prozess – nicht vom Menschen
Das Wissen selbst muss zunächst in den Köpfen einiger Schlüsselpersonen vorhanden sein. Darauf sollte der Testprozess aufbauen. Solange dieses Wissen nicht ausreichend strukturiert und dokumentiert ist, wird Testen sehr schwierig. Die ISTQB-Standards und ISO/IEC/IEEE 29119 betonen beide, dass Testen langfristig nur dann funktioniert, wenn der Prozess wiederholbar ist – und nicht als reine Brandbekämpfung betrieben wird.
In der Praxis ergibt sich jedoch häufig folgendes Bild:
1. 3–5 Schlüsselpersonen verstehen das System und die Geschäftsprozesse wirklich.
2. Ein wesentlicher Teil der Testfälle und Erfahrungen existiert „im Kopf“ oder in verstreuten Excel-Tabellen und alten Confluence-Seiten.
3. Die Dokumentation der End-to-End-Prozesse ist unvollständig oder veraltet.
„Judith weiß, wie man das end-to-end testet, sie macht das seit neun Jahren“ – in der Praxis kann es durchaus sein, dass Judit bisher für das Testen ausgereicht hat. Für das Testen eines komplexen Systems ist sie allein aber mit Sicherheit nicht mehr genug, und es wäre sehr riskant, ihr diese Aufgabe im Alleingang zu überlassen. Ganz zu schweigen von den versteckten Gefahren der Haltung „Wir haben keine Zeit zu dokumentieren, der Release muss zuerst raus“.
Was ist daran problematisch? In einem solchen Setup kann man schlicht nicht genau sagen:
- was tatsächlich getestet wurde und was nicht
- man kann nicht sinnvoll priorisieren
- man weiß nicht, was man bei Zeitdruck gefahrlos weglassen kann
- und man kann die QA-Kapazität nicht schnell skalieren, weil das Wissen nicht auf Prozessebene übertragbar ist.
Dritter Grund: Fehlende Inhouse-Testkompetenz und -kapazität
Leider wird QA vielerorts noch immer als eine Art „letzte Kontrolle“ betrachtet, nicht als strategisches Qualitätsmanagement. Der Testblick auf strategische IT-Entscheidungen tritt häufig in den Hintergrund. Konkret heißt das:
- es gibt keine einheitliche, unternehmensweite Teststrategie und Methodik, nur QA auf Projekt- und Vendor-Ebene „im Kleinen“,
- der Großteil der QA-Arbeit findet auf der Vendor-Seite statt, ohne starke Testmanagement-Rolle auf Auftraggeberseite,
- die UAT-Reife auf Fachbereichsseite ist niedrig: Oft wird nur kurz auf das UI geschaut – Aufgabe erledigt.
Und wenn dann etwas schiefgeht, „springen“ die Fehler zwischen den Beteiligten hin und her, ohne dass jemand die QA gesamthaft zusammenhält.
Vierter Grund: Permanenter Release-Druck, kurze Time-to-Market
IT ist heute in jeder Branche ein Kernbestandteil des Geschäfts. Bei Banken sind es Mobile Apps und Online Banking, bei Telcos das Self-Service-Portal, bei Herstellern die digitale Lieferkette und Partnerportale, im B2B-Bereich das API-Ökosystem. Das Management hat Recht, schnelle Releases und schnellen ROI zu verlangen – aber den Zeitbedarf für Qualität kalkulieren wir nur ungern ein.
Publikationen in IEEE Software und mehrere Branchenstudien zeigen immer wieder:
- das Verhindern eines kritischen Fehlers in einer frühen Testphase kostet „1 Einheit“,
- derselbe Fehler in der System- oder UAT-Phase kostet „10–50 Einheiten“,
- wird er erst in Produktion entdeckt, kostet er „100+ Einheiten“ (Ausfallzeiten, SLA-Strafen, Reputationsschäden, Kundenverlust).
Trotzdem hört man in den letzten Wochen vor dem Go-Live oft: „Nur dieses eine Mal lassen wir die vollständige Regression weg, es ist ja nur eine kleine Änderung.“ Genau aus diesen „kleinen“ Änderungen werden dann schwerwiegende Produktionsfehler, die ganze Prozesse unbrauchbar machen.
Wo genau bricht der IT-Prozess also tatsächlich?
Aus dem oben Gesagten wird deutlich, was fehlt – fassen wir es noch einmal zusammen:
✘ Keine Teststrategie und keine einheitliche, unternehmensweite Testmethodik
Die meisten Organisationen verfügen über irgendeinen projektspezifischen Testplan, eine UAT-Checkliste oder vielleicht ein Regressionsexcel. Was fehlt, ist eine einheitliche, unternehmensweite Teststrategie, die klar definiert:
- was „fertig“ für unterschiedliche System- und Release-Typen bedeutet,
- welche Teststufen obligatorisch sind (Unit, Integration, System, E2E, UAT, Non-Functional),
- anhand welcher Kennzahlen (Coverage, Defect Escape Rate, Fehlerrate) ein Release als akzeptabel gilt,
- wie interne QA und Vendor-QA zusammenarbeiten und wer wofür verantwortlich ist.
Ohne zentrale Strategie entwickelt jedes Projekt sein eigenes Regelwerk – mit unterschiedlichen Qualitätsniveaus und Erwartungen. In zwei aufeinanderfolgenden Projekten kann „wir haben ausreichend getestet“ etwas völlig anderes bedeuten, und das Management trifft jede Go-Live-Entscheidung im „Halbdunkel“ .
✘ Kein durchgängig geplantes End-to-End-Regressionstest-Set
Regressionstests schwanken typischerweise zwischen zwei Extremen: Entweder „wir würden gerne alles erneut testen“ (was zeitlich unmöglich ist), oder „wir testen nur das direkt betroffene Modul“ (was in einem integrierten Ökosystem eine Illusion ist).
Die Realität sollte ein priorisiertes, risikobasiertes E2E-Regressionstestset sein, das:
- die Geschäftsprozesse abdeckt, die für Betrieb, Umsatz und Reputation am kritischsten sind (Order-to-Cash, Billing, Partnerverwaltung, Kernbankprozesse etc.),
- querschnittliche Funktionen identifiziert (z. B. Berechtigungen, Pricing, Invoicing), die sich über mehrere Systeme erstrecken,
- zentrale nicht-funktionale Tests (Performance, Security) enthält.
ISTQB und der World Quality Report weisen beide darauf hin – in den meisten Organisationen scheint es keinen formalisierten, gepflegten Regressionskatalog zu geben. Solange dieser fehlt, ist jedes Release eine Art „russisches Roulette“. Das Testen ist halb improvisiert, und bei jedem größeren Incident taucht zwangsläufig die Frage auf: „Warum haben wir das nicht bemerkt?“
✘ Kein wirklicher Platz für das Testen im Projekt
Projekte sind zeitlich begrenzt, der Scope schrumpft selten. Wenn Testen nicht fest im Projektmanagement-Rahmen (durch Gates und Qualitätskriterien) verankert ist, wird die Testzeit zum weichen Scope-Element – und genau dieses wird zuerst gekürzt. Es wird ad hoc getestet, wenn noch Zeit übrig ist.
Ein typischer Ablauf sieht so aus:
- die Testumgebung ist zu spät fertig, dadurch verzögert sich der Integrationstest,
- Performance-Tests werden gestrichen – „dafür haben wir jetzt keinen Spielraum“ oder „da gab es bisher selten Probleme“,
- UAT auf Fachbereichsseite wird verkürzt oder ähnelt eher einem Produktions-Pilot.
In solchen Fällen basieren Entscheidungen darüber, was weggelassen wird, nicht auf einer strukturierten Risikoanalyse, sondern auf schnellen, politisch und termingetriebenen Kompromissen. Das Ergebnis sind unerwartete Fehler in Produktion, nachgelagerte Feuerwehraktionen und – als Krönung – ein Vertrauensverlust gegenüber der IT.
Die Rentabilität der Testautomatisierung: Wann lohnt sie sich und wie wird sie berechnet?
Die Rentabilität der Testautomatisierung ist für Unternehmen entscheidend. Erfahren Sie, welche Faktoren den ROI beeinflussen, wann sich die Investition lohnt und wie sich die häufigsten Fallstricke vermeiden…
Was wird also benötigt? End-to-End-Testmanagement und QA-Governance
In einer Enterprise-Umgebung ist Testmanagement ein eigener Beruf.
Es geht nicht darum, „ein paar Tester zu besorgen“, sondern darum, Qualität auf Systemebene zu planen, zu steuern und zu messen – eingebettet in einen klar definierten Rahmen.
Das bedeutet unter anderem:
- es wird eine End-to-End-Teststrategie erstellt
- QA-Governance ist etabliert
- Qualität wird messbar
End-to-End-Teststrategie | QA-Governance | Skalierbarkeit |
sich an Geschäftszielen und Risiken orientiert | dedizierte Rolle (Testmanager / QA Lead) mit klarer Verantwortung für QA-Regeln | Defect Escape Rate (Fehler in Produktion) |
zur Architektur und zum Delivery-Modell (Waterfall, Agile, SAFe, DevOps) passt | klare Zuständigkeiten zwischen internen Teams und Vendoren | Regressionsabdeckung |
verpflichtende Teststufen, Qualitätsgates und Reportingregeln festlegt | Qualitätssteuerung auf Basis einheitlicher Metriken | Fehlerrate in geschäftskritischen Prozessen |
SLA-/OLA-Erfüllung aus QA-Sicht |
✔ Testautomatisierung dort, wo sie echten Mehrwert bringt
Bei der Planung von Testautomatisierung sind die Kernfragen: Was lohnt sich zu automatisieren? Auf welcher Ebene (Unit, API, UI, E2E)? Mit welchem Ziel (Integration, vollständige Regression, Smoke, Non-Functional)?
Testautomatisierung ist insbesondere in folgenden Fällen sehr effektiv:
- auf API-Ebene in Microservice- und integrationslastigen Umgebungen, da sie weniger fragil ist als rein UI-basierte Automatisierung,
- bei der automatisierten Regression kritischer Geschäftsprozessez. B. in Buchhaltungs- oder Core-Banking-Grundprozessen,
- bei automatisierten Testläufen integriert in CI/CD mit Qualitätsgates.
Die meisten Testautomatisierungsinitiativen versanden in der Wartung von UI-Skripten, und nur ein kleiner Teil der Unternehmen schafft es, Automatisierung auf einer strategischen, E2E-Ebene zu nutzen. Der Ausweg besteht darin, Automatisierung vom Testmanagement ausgehend zu planen, an Business-Prioritäten auszurichten, und auf realistischen ROI-Berechnungen aufzubauen. Nicht die Technologie, sondern die Strategie entscheidet, was sich lohnt.
✔ AI-assisted Testing – ein aufkommender, aber bereits greifbarer Trend
AI-/ML-basierte Unterstützung im Testen kann in vielen Formen auftreten: prädiktive Fehlererkennung, automatische Testfallgenerierung, Testskripte, die sich an UI-Änderungen anpassen, Log-Analyse und Anomalie-Erkennung. Laut Prognosen von Gartner und Forrester wird ein erheblicher Teil der QA-Tools in den nächsten 3–5 Jahren solche Fähigkeiten erhalten.
Dies kann dabei helfen, Regressionssätze schneller zu pflegen und zu optimieren, ungetestete Bereiche zu identifizieren und manuelle, repetitive QA-Arbeit zu reduzieren. Wichtig ist jedoch: Das ersetzt nicht die Grundlagen. Wenn es keine Teststrategie, keinen E2E-Regressionkatalog und keine klare QA-Governance gibt, wird AI lediglich den „intelligenten Chaosmodus“ unterstützen. Der echte Mehrwert entsteht dort, wo bereits stabile QA-Prozesse vorhanden sind und AI diese beschleunigt, statt sie ersetzen zu wollen.
Wenn Sie bei der Wirksamkeit Ihres eigenen Testprozesses unsicher sind, gehen Sie diese Checkliste durch …
Wer bereits mehrere schmerzhafte Produktionsfehler oder stark verzögerte Releases erlebt hat, stellt sich möglicherweise die Frage, wie gut der aktuelle Testprozess wirklich zur eigenen Enterprise-Umgebung passt.
Aus dem Inneren heraus ist es oft schwierig, darauf eine ehrliche und objektive Antwort zu geben. Deshalb lohnt sich eine externe, unabhängige QA-Perspektive, die nicht aus Entwickler- oder (nur) Vendor-Sicht schaut, sondern aus Unternehmens- und Business-Risikosicht prüft:
- Gibt es eine einheitliche Teststrategie, Testmethodik und QA-Governance?
- Existiert ein priorisiertes E2E-Regressionstestset für die kritischsten Prozesse?
- Wie effektiv ist die aktuelle Testautomatisierung, und wo würde eine Erweiterung Sinn ergeben?
- Wie gut passt der QA-Prozess zu agilen/DevOps/hybriden Arbeitsweisen?
- Wie werden Integrations- und nicht-funktionale Risiken gehandhabt?
Wobei kann TestIT unterstützen?
Bei TestIT bieten wir mit dem beschriebenen Ansatz Testmanagement - und QA-Beratungsleistungen an, die:
- die aktuelle QA-Reife bewerten,
- auf Basis von Industriestandards (ISTQB, ISO/IEC/IEEE 29119) und Trends (World Quality Report, Gartner, Forrester) Entwicklungsrichtungen empfehlen,
- dabei helfen, eine Testmethodik aufzubauen oder den End-to-End-Testmanagementrahmen zu verfeinern,
- und die Ausarbeitung einer realistischen, auch geschäftlich gut vertretbaren Testautomatisierungsstrategie unterstützen.
All dies mit vielen Jahren solider Enterprise-Erfahrung im Rücken: Wir haben bereits die Systeme zahlreicher Marktführer durchleuchtet und erfolgreich Softwaretest- und Testmanagementaufgaben in ihren komplexen IT-Landschaften durchgeführt.
Wenn Sie Fragen haben, sprechen Sie uns an – schon ein kurzer, fokussierter QA-Audit kann viele Blindspots sichtbar machen.
FAQ
1. Ab welcher Unternehmensgröße lohnt sich eine eigene Testmanagement-/QA-Governance-Funktion?
Definitiv dort, wo mehrere geschäftskritische Systeme (ERP, CRM, Billing, Core Banking, Logistik etc.) parallel laufen, jährlich mehrere aufeinander aufbauende Projekte und Releases stattfinden und mehrere Vendoren gleichzeitig arbeiten. In einer solchen Umgebung lohnt es sich, QA eigene „Beine“ zu geben: mit einem dedizierten Testmanager, QA Lead und einem klaren Governance-Rahmen.
2. Wie fangen wir an, wenn wir bisher hauptsächlich manuell und ad hoc getestet haben?
Sie müssen nicht alles auf einmal umkrempeln. In der Praxis bewährte Schritte:
- ein schneller Testing Survey / QA-Statuscheck (Überblick über Prozesse, Tools, Rollen),
- die Auswahl ein bis zweier geschäftskritischer Prozesse und der Aufbau eines E2E-Regressionstestkatalogs dafür,
- Pilotautomatisierung für die stabilsten und wichtigsten Tests,
- schrittweise Ausweitung des Ansatzes auf das gesamte Unternehmenssystemportfolio auf Basis der gesammelten Erfahrungen.
3. Brauchen wir wirklich einen externen QA-Partner, wenn wir ein eigenes IT-Team haben?
Nicht für alles, aber in bestimmten Situationen zahlt es sich sehr aus. Ein externer Partner:
- bringt einen objektiven Blick auf strukturelle Probleme, die von innen schwer zu erkennen sind,
- stellt spezialisiertes Know-how bereit (Testmanagement, nicht-funktionales Testen, Automatisierungsstrategie, AI-assisted Testing),
- verkürzt die Lernkurve durch die Übernahme bewährter Methoden und Best Practices.
Ziel ist nicht, dass der externe Partner die QA übernimmt, sondern dass er die interne Qualitätssicherung stärkt und auf ein höheres Niveau hebt.
