Unit-Tests, Integrationstests, manuelle Tests – die Ebenen sind bekannt. Die Faustregel dabei: Je aufwändiger ein Test, desto gezielter sein Einsatz.
- Unit-Tests bilden das Fundament. Sie laufen mehrfach und – wo notwendig – auch sofort. Dieses Prinzip der testgetriebenen Entwicklung stellt sicher, dass Testbarkeit von Anfang an mitgedacht wird.
- Integrationstests prüfen das Zusammenspiel mit benachbarten Systemen oder Schichten, von der Datenbank bis zur SAP-Anbindung. Dafür braucht man eine laufende Umgebung. Der Aufwand ist höher, jedoch notwendig, um die korrekte Funktion der Komponenten miteinander zu gewährleisten.
- Manuelle Tests kommen dort zum Einsatz, wo Automatisierung an ihre Grenzen stößt: bei komplexen Aktionsfolgen, optischen Prüfungen oder Szenarien, die sich nicht sinnvoll durch ein System skripten lassen.
Der Motor dahinter: CI/CD-Pipelines
Testsysteme dürfen nicht nur existieren, sie müssen laufen und das zuverlässig, automatisch und idealerweise mit sofortigem Feedback. Dafür betreiben wir ein CI/CD-System (Continuous Integration und Continuous Delivery/Deployment), das jeden Code-Push zum Auslöser macht.
Sobald Änderungen in das Repository eingecheckt werden, startet automatisch eine Pipeline: Die Software wird zusammengebaut, Unit-Tests ausgeführt und anschließend für die Integrationstests die vollständige Laufzeitumgebung bereitgestellt. Schlägt ein Test fehl, kommt die Meldung sofort – bevor der Code integriert wird.
Technisch gesehen sieht es folgendermaßen aus: Merge Requests sind an eine erfolgreiche Pipeline geknüpft. Ist sie nicht grün, ist die Integration blockiert. Kein fehlerhafter Code kommt weiter, solange das Problem nicht behoben ist. Dieses Prinzip zieht sich durch den gesamten Prozess.
Diese automatisierten Tests sind eine Investition. Der Aufwand entsteht einmalig beim Schreiben. Danach kostet jede weitere Ausführung fast nichts. Ein manueller Test hingegen kostet jedes Mal denselben Aufwand. Wer langfristig denkt, automatisiert früh.
Ein Beispiel aus der Praxis
Ein Kunde wünscht sich eine Funktion, die so in nscale noch nicht existiert.
Der Weg von dort bis zur Auslieferung folgt einem klaren Ablauf: Das Produktmanagement bewertet die Anforderung, der Product Owner formuliert eine User Story mit Akzeptanzkriterien, das Team klärt im technischen Refinement die Details. Dann beginnt die Implementierung und parallel dazu entstehen bereits die Tests. Nicht danach, sondern gleichzeitig.
Sobald der Code eingecheckt wird, läuft die Pipeline. Fehler kommen sofort zurück. Im sogenannten Code Review bewertet eine zweite Person nicht nur den Produktionscode, sondern ausdrücklich auch die Tests. Denn die größte Falle beim Testen ist die „falsche Sicherheit“.
Ein Test, der formal grün ist, aber nicht das Richtige prüft, ist schlimmer als kein Test: Er suggeriert Qualität, wo keine ist. Deshalb ist die inhaltliche Qualität der Tests genauso verbindlich wie die des Produktionscodes selbst.
Danach kann die Funktionalität bereits dem ausgewählten Kunden gezeigt werden, noch vor dem Release. So entsteht echtes Feedback, bevor etwas produktiv geht. Was nicht passt, fließt in die nächste Iteration ein.
Wohin sich Testing entwickelt
Der Trend ist eindeutig: mehr Abdeckung in weniger Zeit. Was früher Tage dauerte, lässt sich heute in Minuten automatisiert abwickeln – Browser-Tests, Lasttests, Performance-Tests inklusive.
Der nächste Schub kommt durch KI. In unseren Entwicklungsumgebungen ist sie bereits integriert. Sprachmodelle können bestehenden Code lesen, Methoden und Strukturen interpretieren und daraus sinnvolle Testfälle ableiten. Eine Entwicklerin oder ein Entwickler definiert das Interface, der KI-Agent generiert die Tests, während parallel an der Implementierung geschrieben wird.
Das verschiebt die Rolle der entwickelnden Person: weg von zeitaufwändiger Routine, hin zu Konzeption, Analyse und Verifikation. Denn was die KI generiert, muss verstanden und bewertet werden. Diese Prüfkompetenz wird zur Schlüsselqualifikation – und wer sie früh entwickelt, wird einen echten Vorsprung haben.
Fazit
Testing ist kein Selbstzweck und kein nachgelagerter Schritt, den man irgendwann am Ende noch erledigt, sondern die konsequente Umsetzung einer Überzeugung, die bei uns von der ersten User Story bis zur Auslieferung greift: Wer gute Software bauen will, braucht ein klares Verständnis davon, was getestet werden muss und warum – auf der richtigen Ebene, mit dem richtigen Aufwand.
Was sich gerade verändert, ist das Tempo. KI-gestützte Werkzeuge machen es möglich, Testfälle schneller zu generieren, Lücken in der Abdeckung früher zu adressieren und Routinearbeit zu delegieren, ohne die Verantwortung für Qualität abzugeben.
