Tests im Projekt? Oft erst Thema, wenn es fast zu spät ist. In Teil 5 unserer Gesprächsreihe mit Architekt Adam (ARCH) und Anforderungsmanager Manfred (AM) geht es um einen der größten Klassiker in IT-Projekten: Das Testen wird übersehen – und plötzlich muss alles unter Zeitdruck passieren.
Fünftes Treffen: Wenn Tests erst am Ende miteinbezogen werden
Ort des Geschehens: Wieder ein Gespräch am Spielfeldrand – diesmal mit einer Mischung aus Erleichterung und Kopfschütteln.
ARCH: Manfred, du glaubst nicht, was diese Woche passiert ist, ich bin fast vom Stuhl gefallen.
AM: Deine Frau hat dir dein Lieblingsessen gekocht? Dein Sohn hat eine 1 in Mathe?
ARCH: Nein! Also doch, meine Frau hat mein Lieblingsessen gekocht. War auch bitter nötig. Was ich meine: Wir sind eine Woche vor Abgabe und da fällt dem Projektmanager ein, dass sich noch niemand um den Test gekümmert hat. Wäre das nicht seine Aufgabe gewesen? Wenigsten einen Qualitätsmanager einzubinden? Ich habe ihn ja schließlich jede Woche darauf aufmerksam gemacht, dass das noch fehlt …
AM: Oh, der Klassiker. Niemand denkt ans Testen und der Tester darf dann in 30 % der Zeit alles machen und wird zur Rechenschaft gezogen, wenn es ein großes Problem gibt. Jetzt sag mir bitte nicht, dass du noch eben ein grobes Testvorgehen aus dem Ärmel schütteln darfst?
ARCH: Oh doch!
AM: Hast du schon Ideen?
ARCH: Ideen ja, aber ob das den Anforderungen genügt, weiß ich nicht. Wir konzipieren eine Anwendung mit Frontend, Backend und Datenbank. Im Backend gibt es Schnittstellen zu anderen Systemen und es gibt eine Datenbank-Synchronisation zur Golden Source von gewissen Informationen. Ich habe an ein klassisches Setup mit viel Automatisierung gedacht. JUnit-Tests, Testautomatisierung für fachliche Use Cases inklusive UI-Test und ein manueller Integrationstest überall dort, wo wir mit automatisierten Tests an Grenzen stoßen. Dazu Performance-Tests und ein Pen-Test.
AM: Das klingt schon mal nicht so verkehrt. Wie testet ihr den DB-Sync? Gibt es eine initiale Datenbeladung, die gesondert getestet werden muss?
ARCH: Oh, guter Punkt. Den DB-Sync hätten wir durch Integration in der Testumgebung implizit über die fachlichen Tests getestet. Aber das stößt bei der Initialbefüllung auf Probleme. Ich glaube, hier braucht es noch einen gesonderten Test.
AM: Ja, das wird häufig übersehen. Ebenfalls wird häufig das Test-Setup unterschätzt. Wie genau ist die Testumgebung bestückt? Welche Einschränkungen gibt es? Welche Qualität haben die Testdaten? Welche Performance ist zu erwarten? Wer kümmert sich?
ARCH: Ähhhh … Also …
AM: Ich sehe schon, ich treffe da einen wunden Punkt. Dann hast du dir bestimmt schon Gedanken gemacht, wann welche Tests laufen? Also im Wasserfall erst alles entwickeln, dann testen, oder doch eher agil nach jedem Feature? Was sagt denn eigentlich der Kunde dazu, wie getestet werden soll? Will er selber testen? Was will er testen? Oder will er nur einen Testreport? Kunden sind da sehr unterschiedlich. Wann werden Dinge abgenommen? Handelt es sich um ein agil umzusetzendes Projekt?
ARCH: Ja klar, das Projekt ist agil, also wird in jeder Iteration das jeweilige Inkrement getestet. Durch die hohe Automatisierung können die Testfälle danach regressiv durchgeführt werden.
AM: Sehr gut! Die UI-Tests enthalten auch Barrierefreiheit?
ARCH: Ja klar, Barrierefreiheit ist inzwischen absoluter Standard und wird natürlich mitgetestet. Wir haben da ein Tool, das uns auf etwaige Lücken hinweist.
AM: Das klingt jetzt halbwegs vollständig. Ich kenne deine spezifischen Projektherausforderungen nicht. Da könnte auch noch Testbedarf schlummern, den ich nicht kenne. Beispielsweise wenn eure Anwendung KI-Anteile enthält. Es wird auch Unterschiede geben, je nachdem ob eure Anwendung öffentlich zugänglich ist oder bspw. für die Mitarbeiter eures Kunden gedacht ist. Die Fachlichkeit selbst oder die Branche als Ganze kann auch noch Unterschiede bringen. Eine Anwendung im Public-Sektor hat differenzierte Anforderungen an die Qualität. Andere spezifische Anforderungen existieren im Finance-Sektor, insbesondere bei (Voll-)Banken und Versicherungen. Die Liste könnte ich immer weiterführen, aber ich denke, dass du meinen Punkt verstehst.
ARCH: Ja absolut, hier muss ich mich nochmal hinsetzen und alles durchgehen. Glücklicherweise hatten wir ja über regulatorische Rahmenbedingungen mal recht am Anfang gesprochen, so dass ich hier nicht von vorne anfange.
Erkenntnis des Tages: Testen ist kein „Nice-to-have“
Diese Unterhaltung zeigt deutlich: Testkonzepte gehören von Anfang an in jedes Projekt – nicht erst in die Endphase.
Gerade in komplexen IT-Projekten im öffentlichen Sektor sind Teststrategie, Testumgebung und Abnahmekriterien entscheidend, um Risiken zu minimieren und die Qualität zu sichern.
Wie geht’s weiter?
Tests sind kein „Nice-to-have“, sondern ein zentrales Qualitätsmerkmal. Doch was passiert, wenn die Analyse, die Ausschreibung und die Umsetzung nicht aufeinander abgestimmt sind? Im nächsten Teil der Serie sprechen Adam und Manfred genau darüber – und ziehen Lehren, wie die richtige Balance zwischen Analyse, Projektplanung und Umsetzung aussehen muss.
Bereits erschienen
Teil 1: Ein neues Projekt und viele offene Fragen
Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?
Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes
Teil 4: Was braucht man wirklich, um zu schätzen?
Teil 5: Testen vergessen?
Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!
Teil 7: Fazit und Ausblick
