„Bei mir läuft es“ ist einer der häufigsten Sätze in Softwareprojekten. Der Grund liegt selten im Code allein, sondern in der Umgebung: andere Versionen, eine fehlende Schnittstelle, eine abweichende Konfiguration. Eine gut geplante Testumgebung sorgt dafür, dass Testergebnisse aussagekräftig sind und Fehler dort auffallen, wo sie günstig zu beheben sind, und nicht erst in der Produktion.
Eine Testumgebung ist die technische Umgebung, in der Software getestet wird. Dazu gehören Server oder Container, Betriebssystem, Datenbanken, Middleware, die Konfiguration der Anwendung, die Anbindung an andere Systeme und die Testdaten. Sie ist bewusst von der Produktion getrennt, damit Tests weder echte Kunden noch echte Abläufe beeinträchtigen.
Welche Testumgebungen ein Projekt braucht, wird grundsätzlich in der Teststrategie festgelegt. Wie sie für ein konkretes Release genutzt werden, steht im Testkonzept.
Die meisten Projekte arbeiten mit einer Kette von Umgebungen, die mit jeder Stufe näher an die Produktion heranrückt. Die Bezeichnungen unterscheiden sich, das Prinzip ist ähnlich:
Nicht jedes Projekt braucht alle Stufen als eigene Umgebung. Kleine Teams fassen Integration und Abnahme oft zusammen. Entscheidend ist, dass für jede Teststufe klar ist, wo sie stattfindet und welcher Softwarestand dort liegt.
Eine exakte Kopie der Produktion ist teuer und selten nötig. Sinnvoller ist die Frage, welche Unterschiede ein Testergebnis verfälschen können. Diese Punkte sollten zwischen Staging und Produktion übereinstimmen:
Abweichungen sind dagegen oft vertretbar: weniger Server, kleinere Rechenleistung oder simulierte Fremdsysteme, solange das Team die Unterschiede kennt und bei der Bewertung von Ergebnissen berücksichtigt. Für Lasttests gilt eine Ausnahme: Ergebnisse aus einer deutlich kleineren Umgebung lassen sich nur eingeschränkt auf die Produktion übertragen.
Viele Anwendungen hängen an Systemen, die im Test nicht oder nur eingeschränkt verfügbar sind: Zahlungsanbieter, Partner-Schnittstellen, Altsysteme anderer Abteilungen. Statt auf diese Systeme zu warten, werden sie nachgebildet.
Ein Stub liefert auf eine Anfrage eine feste Antwort. Ein Mock prüft zusätzlich, ob er wie erwartet aufgerufen wurde. Beide eignen sich vor allem für Komponenten- und Integrationstests und lassen sich gut automatisieren.
Bei der Service-Virtualisierung wird das Verhalten eines Fremdsystems umfassender simuliert, etwa mit unterschiedlichen Antworten, Verzögerungen und Fehlerfällen. So lassen sich auch Situationen testen, die mit dem echten System kaum herzustellen sind, zum Beispiel ein Zeitüberschreitungsfehler beim Zahlungsanbieter.
Wichtig: Spätestens in Staging oder in der Abnahme sollte gegen die echten Schnittstellen oder deren offizielle Testsysteme geprüft werden. Eine Simulation bildet immer nur ab, was das Team über das Fremdsystem weiß.
Gehen Sie von den geplanten Tests aus: Welche Teststufen gibt es, welche Systeme und Schnittstellen werden jeweils gebraucht, wie viele Teams testen parallel? Daraus ergibt sich, wie viele Umgebungen nötig sind und wie produktionsnah sie sein müssen.
Beschreiben Sie für jede Umgebung Zweck, Softwarestand, angebundene Systeme, Datenbasis und Zugriffsrechte. Eine einfache Übersicht genügt, solange sie aktuell gehalten wird und für alle Beteiligten auffindbar ist.
Umgebungen, die per Skript oder als „Infrastructure as Code“ aufgebaut werden, lassen sich reproduzierbar erstellen und bei Bedarf neu aufsetzen. Container helfen, dieselben Versionen auf allen Stufen zu verwenden. Handarbeit beim Aufbau ist eine der häufigsten Ursachen dafür, dass Umgebungen sich unbemerkt auseinanderentwickeln.
Legen Sie fest, wann und wie neue Versionen in welche Umgebung gelangen: automatisch nach jedem erfolgreichen Build, täglich oder nur auf Freigabe. Für die Abnahme und Staging ist ein kontrollierter Rhythmus sinnvoll, damit laufende Tests nicht durch einen neuen Stand unterbrochen werden.
Wer behebt einen Ausfall, wer spielt Datenstände zurück, wer entscheidet über Belegung und Freeze-Phasen? Ohne benannte Verantwortliche wird die Testumgebung schnell zum Engpass, über den niemand entscheiden kann.
Mit dem Aufbau ist es nicht getan. Im laufenden Projekt geht es darum, dass die Umgebungen verfügbar, stabil und nachvollziehbar bleiben. Bewährt haben sich:
Im Projekt ist das eine typische Aufgabe des Testmanagements in enger Abstimmung mit Entwicklung und IT-Betrieb.
In agilen Teams wird mehrmals täglich integriert und getestet. Feste, lange laufende Umgebungen geraten dabei schnell an ihre Grenzen. Viele Teams setzen deshalb zusätzlich auf kurzlebige Umgebungen: Für einen Branch oder Pull Request wird automatisch eine eigene Umgebung aufgebaut, getestet und danach wieder entfernt. Das setzt automatisierte Bereitstellung und selbst angelegte Testdaten voraus, zahlt sich aber durch schnelleres Feedback aus.
Für die Testautomatisierung ist eine stabile Umgebung Voraussetzung: Fallen automatisierte Tests wegen Umgebungsproblemen aus, verliert das Team schnell das Vertrauen in die Ergebnisse. Wie das Testen im Sprint insgesamt organisiert wird, lesen Sie im Artikel zum agilen Testen in Scrum.
Eine Testumgebung ist kein Nebenprodukt der Entwicklung, sondern Teil der Qualitätssicherung. Wer den Bedarf aus den Teststufen ableitet, die wichtigsten Unterschiede zur Produktion kennt, Fremdsysteme gezielt simuliert und Aufbau wie Deployments automatisiert, bekommt Testergebnisse, denen das Team vertrauen kann, und deutlich weniger Überraschungen beim Go-live.
Eine Testumgebung ist die technische Umgebung, in der Software getestet wird: Server oder Container, Datenbanken, Konfiguration, Schnittstellen zu anderen Systemen und Testdaten. Sie ist von der Produktion getrennt, damit Tests keine echten Kunden, Daten oder Abläufe beeinträchtigen.
Testumgebung ist der Oberbegriff für alle Umgebungen, in denen getestet wird. Staging, auch Preproduktion genannt, ist die letzte Stufe vor dem Go-live und soll der Produktion so weit wie möglich entsprechen. Dort werden Releases abschließend geprüft, etwa mit Abnahme-, Regressions- und Lasttests.
Das sollte im Projekt ausdrücklich festgelegt werden. Häufig betreibt der IT-Betrieb oder ein DevOps-Team die Infrastruktur, während das Testmanagement Bedarf, Belegung und Freigaben steuert. Wichtig ist eine benannte Ansprechperson, die über Deployments, Datenstände und Ausfälle entscheidet.
30 Minuten Erstgespräch — kostenlos und unverbindlich. Wir schauen gemeinsam auf Ihre Testumgebungen und zeigen, wo Tests verlässlicher und schneller werden können.
Jetzt Erstgespräch vereinbarenMehr zu unserer Leistung: Software-Qualitätssicherung und Testmanagement in Hamburg →
Passend dazu: Testdatenmanagement: Testdaten planen und schützen →