Produktivnahe Testumgebung: agile Prozesse richtig testen

… das war die Aussage von Jeanette Süßer, auf die Frage, ob es für den Aufbau von Testumgebungen feste Regeln gibt. Im Grunde ist es bei jeder Installation von agorum core anders und immer abhängig von der Konfiguration die beim Kunden im Einsatz ist. Wichtig ist aber immer, dass neue Workflows, Updates und Co. in einer produktivnahen Testumgebung geprüft werden. Lesen Sie hier die Antworten auf die häufigsten Fragen zum Thema produktivnahe Testumgebungen von Jeanette Süßer:

Was genau heißt produktivnahes Testsystem?

Jeanette Süßer (JS): Das Schlüsselwort ist “produktivnah”. Im Idealfall ist es eine Kopie der Realumgebung. Das heißt, die Speicherressourcen sollten dem Produktivsystem entsprechen. Wenn die reale Umgebung 2 Terabyte Speicherplatz hat, dann sollte die Testumgebung ähnlich viel Platz haben. Bei den anderen Ressourcen, wie z. B. RAM oder CPU, die auf 100 User ausgelegt sind, darf es ggf. weniger sein. Trotzdem sollte ein Minimum nicht unterschritten werden. Unseren Kunden schicke ich oft unser Hardware-Dokument, wo die Parameter ausführlich beschrieben sind. Soviel zu den Ressourcen und der Ausstattung eines Testsystems, was sich aber auch hinter “produktivnah” verbirgt und für gute und reale Tests noch viel wichtiger ist, sind die vorhandenen und aktuellen Daten. Es hilft nichts, mit Pseudotestdokumenten irgendeinen klinischen Test durchzuführen und dann basierend darauf ruhigen Gewissens einen Live-Gang zu planen. Ich könnte da nicht ruhig schlafen.

Was für einer Maschine eignet sich nicht für eine Testumgebung?

JS: Was ich häufig erlebe, ist der fünf Jahre alte Rechner aus dem Keller, der für die Testumgebung herhalten muss. Da sind wir weit weg von einer produktivnahen Umgebung. Das Problem dabei ist, dass der Rechner zu wenig Ressourcen hat und in die Knie geht. Das Testen wird für alle Beteiligten zu einer mühseligen Angelegenheit.

Wenn es viele Möglichkeiten gibt, welches sind denn die Klassiker?

JS: Seit die Virtualisierung die IT erobert hat, ist das sicher die gängigste Variante. Es gibt aber auch alt herkömmliche Methoden, die zwar umständlich sind, aber auch funktionieren:

1. Produktivnahes Testsystem im virtuellen Umfeld:

Hier lassen sich sehr einfach komplette Kopien (Klon) der produktiven Umgebung erstellen und sind damit perfekte Abbilder und folglich produktivnahe Testumgebungen. Oder gibt es auch Möglichkeiten, aus der Datensicherung heraus ad hoc ein System zu erstellen und dieses entspricht dann der Realumgebung von vor ein paar Stunden. Eine perfekte Anleitung gibt es hier nicht, da der Markt im Virtualisierungsumfeld viel bietet. Wie wir es bei agorum handhaben hat Oliver Schulze in diesem Blogbeitrag beschrieben.

2. Fullcopy von Server A zu Server B:

Dieser Weg ist möglich, aber gerade bei größeren Datenmengen eher unpraktisch. Da für die Dauer, der Copy der Daten das Produktivsystem nicht laufen darf und daher nicht gearbeitet werden kann. Je nach Infrastruktur und Menge kann es natürlich unglaublich lange dauern. Auch ist klar, das System ist immer ein Abzug vom aktuellen Stand, sprich ab diesem Zeitpunkt veraltet es zunehmend. Möchte man beim nächsten Projekt erneut vorbildlich mit einem produktivnahen System testen, muss man genau genommen die Erstellung erneut vornehmen. Mit jedem Mal ist das System größer und die Dauer entsprechend länger.

3. Testumgebung aus den Backupdaten:

Das Backup der Systeme und Daten könnte man als Schatz der Unternehmen bezeichnen, den es mit Leib und Leben zu schützen gilt. Viele nicken jetzt vermutlich und doch wissen wir alle, dass leider gerade an diesem Punkt oft gespart wird. Und dann heißt es irgendwann “ach hätten wir doch …”. Aber das ist ein anderes Thema. Gehen wir davon aus, dass ein valides Backup der Daten vorliegt, dann gibt es natürlich je nach Backupstrategie auch unterschiedlichste Möglichkeiten, aus diesen Daten heraus ein Testsystem zu erstellen. Den virtuellen Weg hatte ich bereits erwähnt, aber auch mit Restore der Daten in eine geeignete Umgebung ist es möglich. In diesem Fall natürlich von Vorteil, dass der Produktivbetrieb ungehindert weiterläuft.

4. agorum cloud:

Für unsere Cloud Kunden bieten wir die komfortable Möglichkeit, auf Knopfdruck eine autarke Testumgebung auf Basis der aktuellen Daten zu starten. Diese Möglichkeit zu haben, war uns ausgesprochen wichtig und ein zentraler Punkt bei der Konzeptionierung des technischen Aufbaus in der Cloud.

Was sind denn die neuralgischen Stellen beim Testen?

JS: Der schlimmste Fall ist, wenn gar nicht getestet wird und neue Konfigurationen direkt ins Produktivsystem eingespielt werden. Daraus werden dann i. d. R. immer Supportfälle.

Der Fokus sollte in jedem Fall auf den elementaren Prozessen liegen. Das kann beliebig komplex sein, immer abhängig von der Konfiguration. Sicherlich ist es immer wichtig, etwaige Schnittstellen zu testen, das können implementierte Prozesse über REST-Services oder auch trivialere Schnittstellen im Bereich Mailarchivierung sein. Jede ist für sich elementar für den Prozess und muss funktionell getestet werden.

Aber nicht nur Funktionen stehen im Fokus beim Testen, sondern auch das Mitwirken im Projekt im Rahmen der agilen Konfigurationsentwicklung. Umso intensiver die Tests, umso besser das Produkt, das am Ende Projektes herauspurzelt. Der goldene Gral ist ein Go Live mit einer Konfiguration zu machen, die keinerlei Änderungswünsche mehr offenlässt und die Anwender zufrieden und mit Spaß ihrer Arbeit nachgehen können. Da ist nur zu schaffen, wenn diejenigen, die mit dem Prozess arbeiten sollen, intensiv an der Entwicklung teilhaben und hierbei ist das Testing essenziell.

Was ist bei Schnittstellen so kritisch?

JS: agorum core hat in nahezu allen Einsätzen bei unseren Kunden eine aktive Anbindung an Fremdsysteme. Die häufigsten Schnittstellen sind zu ERP Systemen, zu Datev, zur FiBu, zu SAP usw. Schnittstellen in einer Testumgebung nachzustellen, ist nicht trivial und hängt von zu vielen Faktoren ab, als das wir hier alle Einzelfälle beschreiben können. Aber allgemein gilt:

Wenn das Testsystem gestartet wird, müssen Sie sicherstellen, dass dieses keine Produktivdaten “klauen” kann. Das kann zum Beispiel dann passieren, wenn Dokumente automatisiert von einem Fremdsystem geholt werden und durch das agorum core docform Modul verarbeitet werden und danach weitere Prozesse oder Schnittstellen angesteuert werden.

Und bei Postfächern?

JS: Den Satz “Wo sind denn unsere ganzen Mails…” höre ich öfters und in den meisten Fällen finden wir sie auch wieder 😉 Auch hier gilt dasselbe wie bei den Schnittstellen: Das Testsystem darf die E-Mails nicht vom Produktivsystem “klauen”. Da die Daten von einer produktivnahen Kopie im Testsystem enthalten sind, können trotzdem die ganzen Prozesse getestet werden. Spezialfälle können immer noch manuell eingefügt werden.

Wie aktuell sollte eine produktivnahe Testumgebung sein?

JS: So aktuell wie möglich. Nehmen wir mal das Beispiel vom Umstieg von Lucene auf SolR: das hat schon was von einem Motorwechsel. Wir müssen jede Schraube bzw. jede Datei anschauen. Dafür muss die Testumgebung absolut aktuell sein.

Was ist Deine Empfehlung für agorum Kunden?

JS: Generell gilt: Wenn Arbeiten im System gemacht werden, zum Beispiel Updates oder Einbinden neuer Ablageregeln sollte dies immer in einer Testumgebung entwickelt und geprüft werden. Und wenn automatisierte Prozesse im Einsatz sind, ist es doppelt und dreifach wichtig.

Ich empfehle agorum Kunden, die zum Thema Testumgebungen Fragen oder schon konkrete Vorhaben planen, bei uns ein Supportticket zu öffnen. In unserem System wird ein Vorgang ausgelöst und je nach Anliegen melden sich die Kollegen aus der Kundenberatung oder der Entwicklung bei Ihnen. Schildern Sie uns möglichst genau, was Sie planen. So, wie Sie es immer machen.

Jeanette, vielen Dank für das Interview.