Testmanagement in IT-Großprojekten

Wie Sie mit einem realistischen Testkonzept Projektrisiken minimieren

In vielen Healthcare IT-Projekten – insbesondere in großen, komplexen Vorhaben mit vielen Beteiligten – gibt es ein bekanntes Muster:

Die Testphase steht auf dem Plan, aber sie wird im Laufe des Projekts immer wieder verschoben, verkürzt oder reduziert. Die offizielle Begründung lautet oft:

„Dafür haben wir später noch Zeit.“

Oder: „Erstmal müssen wir fertig konfigurieren – dann schauen wir.“

Was wie eine pragmatische Entscheidung wirkt, ist in Wahrheit ein Risikoverzicht. Denn gerade wenn es eng wird – personell, zeitlich, fachlich – wird die Testphase nicht weniger wichtig, sondern umso entscheidender. Besonders gilt das für große Klinikprojekte, bei denen nicht nur ein einzelnes Abteilungssystem umgestellt wird, sondern zahlreiche Teilbereiche (z. B. Pflege, Medizin, Verwaltung, Abrechnung) gleichzeitig an einem Stichtag live gehen sollen.

Diese Konstellation bringt völlig andere Anforderungen an Testmanagement, Schnittstellenlogik und Projektsteuerung mit sich und erfordert eine viel frühere, strukturierte Planung der Testphase. Der Fokus liegt dabei nicht auf isolierten Funktionstests einzelner Teilprodukte (Inkremente nach jedem Sprint), wie sie aus Entwicklungsprojekten bekannt sind, sondern auf einem übergreifenden Integrationstest, bei dem Prozesse, Rollen und Schnittstellen im Zusammenspiel erprobt werden.

Und dennoch: In der Praxis wird Testmanagement oft zu spät ernst genommen. Die Gründe sind nachvollziehbar.

Der Druck im Projekt ist hoch, Ressourcen sind knapp, viele Schlüsselpersonen sind bereits doppelt eingebunden und die Vorstellung, jetzt noch eine strukturierte Testphase durchzuführen, wirkt auf viele Beteiligte überfordernd. Vor allem, wenn unklar ist, wer was testet, wie Rückmeldungen verarbeitet werden sollen und ob das Projektteam überhaupt die Kapazitäten dafür hat.

Was dabei übersehen wird: Nicht getestete Funktionen oder unklare Prozesse fallen nicht einfach weg, sie verschieben sich. Und zwar genau in den Moment, in dem sie am schwersten zu beheben sind: im Echtbetrieb, unter Zeitdruck, mit Patient:innen, Nutzenden und Reputationsrisiko.

Warum Testmanagement oft zu kurz kommt

Es gibt kaum ein Projekt, in dem die Testphase nicht eingeplant ist.

Und dennoch zeigen viele Projektverläufe ein ähnliches Bild: Wenn der Zeitplan unter Druck gerät, was in komplexen IT-Projekten eher die Regel als die Ausnahme ist, gehört die Testphase zu den ersten Elementen, die verkürzt oder ganz gestrichen werden.

Die Gründe dafür sind vielfältig, meist nicht technisch, sondern organisatorisch:

Projektmüdigkeit

Nach Monaten intensiver Konzeptarbeit, Abstimmungen und Konfiguration ist das Projektteam erschöpft. Der Wunsch, „endlich zum Abschluss zu kommen“, überlagert oft die Bereitschaft, nochmal einen strukturierten, ressourcenintensiven Zwischenschritt wie die Testphase einzuschieben.

Ressourcenkonflikte

Viele Schlüsselpersonen, insbesondere im fachlichen Bereich,  sind doppelt belastet: Sie arbeiten im Projekt mit, tragen aber gleichzeitig Verantwortung für das operative Tagesgeschäft. Zeit für strukturierte Tests ist da oft schlicht nicht vorhanden.

Fehlende Rollenklärung

Wer ist verantwortlich für das Testmanagement? Wer bereitet die Testumgebung vor? Wer sammelt und bewertet die Rückmeldungen? Ohne klare Zuständigkeiten entsteht leicht ein Vakuum und die Testphase wird zum diffusen „Mitlauf-Thema“, das keine Priorität bekommt.

Der Denkfehler „erst fertig – dann testen“

Viele Projektteams wollen das System zunächst „fertig“ sehen, bevor sie in die Tests einsteigen. Das klingt logisch, ist aber gefährlich: Denn gerade im Übergang von der Konzeption zur Anwendung zeigt sich, ob Prozesse tragfähig, Rollen richtig gedacht und Schnittstellen funktional sind.

Kurz gesagt: Die strukturelle und psychologische Hürde für die Testphase ist hoch.

Und sie steigt, je später sie eingeplant ist.

Was fehlt, ist oft nicht der gute Wille, sondern ein klarer Rahmen, der das Testmanagement realistisch einbindet, ressourcenschonend plant und in die Projektsteuerung integriert.

Was eine Testphase wirklich leisten soll

Oft wird das Testen in Projekten primär als technische Überprüfung verstanden: Laufen die Funktionen stabil? Gibt es Fehler im System? Sind die Schnittstellen korrekt angebunden?

Das ist nicht falsch, aber es greift zu kurz.

Denn eine gut vorbereitete Testphase zeigt nicht nur, ob ein System funktioniert, sondern wie es im realen Arbeitskontext funktioniert und wo Prozesse, Rollen oder Abhängigkeiten in der praktischen Anwendung an ihre Grenzen kommen.

Besonders in komplexen IT-Projekten mit vielen Beteiligten, wie etwa in Krankenhäusern, zeigt sich erst in der Testphase:

• ob Prozesslogiken durchgängig sind,
• ob Benutzerrechte und Rollenkonzepte sinnvoll greifen,
• ob unterschiedliche Fachbereiche tatsächlich synchron arbeiten können,
• und ob das, was im Projektteam „funktional gedacht“ wurde, auch für die tatsächliche Nutzungssituation passt.

Abbildung 1: Was eine Testphase wirklich leisten soll – Funktioniert ein System im realen Arbeitskontext?

In diesem Kontext reicht es nicht, einzelne Funktionen „grün zu testen“. Entscheidend ist, ob die Übergänge zwischen Bereichen funktionieren, ob z. B. eine ärztliche Dokumentation, die die Pflege mitdenkt, ob Leistungen sauber übergeben werden, ob Daten dort ankommen, wo sie gebraucht werden. Genau deshalb ist der integrative Charakter der Tests so wichtig, gerade in multiprofessionellen Projekten mit vielen parallelen Logiken.

Die größten Erkenntnisse entstehen dabei oft nicht durch Fehlermeldungen, sondern durch Rückfragen, durch Diskussionen im Team, durch Aha-Momente:

• „Ach so, diesen Inhalt sieht die Pflege gar nicht?“
• „Wenn die Leistung hier dokumentiert wird, fehlt sie später in der Abrechnung…“

Das sind keine technischen Bugs, sondern strukturelle Klärungen.

Und genau dafür ist die Testphase da: Sie schafft Transparenz über das Zusammenspiel, fachlich, technisch und organisatorisch.

Vor allem aber entsteht in ihr etwas anderes: Ein gemeinsames Verständnis. Ein Dialog darüber, wie die Dinge wirklich laufen, jenseits von Excel-Plänen und Meilensteinen.

Dort, wo Prozesse Menschen berühren, wird Testen zur sozialen Schnittstelle  und gute Projektführung bedeutet, diesen Raum bewusst zu gestalten. Nicht, um alles perfekt zu machen. Sondern um realistisch zu erkennen, wo noch Justierungen nötig sind, bevor es ernst wird.

Typische Missverständnisse und wie man sie auflöst

Viele Probleme in der Testphase entstehen nicht aus mangelnder Bereitschaft, sondern aus falschen Vorstellungen darüber, wie Testen eigentlich funktioniert. Zwei Beispiele begegnen uns dabei besonders häufig:

„Unsere Key User haben keine Zeit für Tests.“

Diese Aussage ist in vielen Projekten berechtigt, aber sie ist nicht das eigentliche Problem. Denn die Frage lautet nicht: Haben die Key User Zeit zum Testen?

Sondern: Wie ist die Testphase strukturiert und wie klar ist ihre Aufgabe definiert?

Wenn Tests unsystematisch „nebenher“ laufen, ohne Briefing, ohne Zeitfenster, ohne Rückkanal, dann entsteht schnell Überforderung oder Frust, vor allem, wenn Rückmeldungen ins Leere laufen.

Ein durchdachtes Testkonzept hingegen gibt einen klaren Rahmen vor: Was genau soll getestet werden? In welcher Tiefe? Mit welchem Ziel?
So lassen sich auch in engen Zeitfenstern effektive Rückmeldungen erzeugen, ohne die Beteiligten zu überlasten.

• Wer nimmt Rückmeldungen entgegen?
• Wer bewertet sie (z. B. fachlich vs. technisch)?
• Wie werden sie priorisiert und dokumentiert?
• Welche Rückläufe gibt es an die Testenden?

Was ein gutes Testkonzept leisten muss und was nicht

Ein gutes Testkonzept ist kein Selbstzweck. Es muss nicht alles abdecken, nicht jede Sonderkonstellation vorwegnehmen und auch nicht jede Projektlogik im Detail abbilden.

Aber es muss das leisten, was im Projektalltag wirklich zählt: Orientierung schaffen, Verbindlichkeit erzeugen und gleichzeitig Spielräume lassen für das Unvorhergesehene.

Konkret heißt das:

Priorisierung statt Vollständigkeit

Nicht alle Prozesse müssen im ersten Testlauf bis ins letzte „Feld“ durchgespielt werden. Wichtig sind die Kernprozesse, die täglich genutzt werden und die Rollen, bei denen Fehler besonders schwerwiegende Folgen hätten. Das Pareto-Prinzip ist hier oft hilfreicher als ein allumfassender Anspruch.

Klare Zuständigkeiten und Entscheidungswege

Wer koordiniert die Testphase? Wer erstellt die Szenarien? Wer bewertet Rückmeldungen und wer entscheidet, welche in die Umsetzung gehen?Ohne diese Fragen vorab zu klären, droht die Testphase zu bröckeln oder im Zweifel ganz zu verpuffen.

Strukturierte, aber einfache Rückmeldeformate

Ob Excel-Listen, digitale Tools oder eine zentrale Ansprechperson, entscheidend ist, dass Rückmeldungen auffindbar, bewertbar und priorisierbar sind. Und dass die Beteiligten wissen, was mit ihrem Feedback passiert.

Bewusste Abgrenzungen

In jedem Projekt gibt es Funktionen oder Fachbereiche, die noch nicht vollständig konfiguriert sind. Ein gutes Konzept benennt auch klar, was (noch) nicht getestet wird und warum. Diese Transparenz ist oft wichtiger als eine vermeintlich lückenlose Testabdeckung.

Fazit: Mit gutem Testmanagement minimieren Sie Projektrisiken

Testmanagement ist kein Add-on in Projekten. Und Testphasen sind keine nachgelagerten Kontrollmechanismen. Sie sind ein zentraler Bestandteil der Umsetzung und oft der erste echte Realitätstest für System, Rollen, Prozesse und Projektlogik.

Gerade in komplexen Projekten zeigt sich: Was nicht getestet wurde, wird nicht automatisch funktionieren; ob es funktioniert, wird lediglich später sichtbar. Und dann oft zu einem Zeitpunkt, an dem Nachjustierungen unter deutlich größerem Druck stattfinden müssen.

Ein gutes Testmanagement hilft, diese Situation zu vermeiden. Nicht, indem es alle Eventualitäten absichert, sondern indem es Klarheit schafft, Verantwortung verteilt und Vertrauen ermöglicht. Denn Testphasen sind mehr als ein technischer Zwischenschritt. Sie sind der Moment, in dem aus Theorie Realität wird, mit allen Reibungen, Fragen und Unsicherheiten, die dazugehören. Und: Testphasen zeigen oft Dinge, für die es keine sofortige Lösung gibt. Wer hier Strukturen bietet und einen Raum für Klärung lässt, führt nicht nur Projekte, sondern Menschen durch Veränderung.

Hinweise:

Interessieren Sie sich für ein ausführliches, praxiserprobtes Testkonzept für Großprojekte in der Healthcare-IT? Katja Schäfer bietet ein solches Testkonzept als kostenlosen Download an.

Wollen Sie als Multiplikatorin oder Meinungsführer über Testmanagement in IT Großprojekten diskutieren? Dann teilen Sie diesen Beitrag in Ihrem Netzwerk.

Katja Schäfer hat im t2informatik Blog weitere Beiträge veröffentlicht, u.a.