Fallstricke bei der Middleware-Verwaltung 9. Unterschiede zwischen Test und Produktion

In dieser Folge der Top-10 der Middleware-Fallen möchten wir die Vorzüge einer sauberen und standardisierten Reihe von (Test-)Umgebungen diskutieren. Manche bezeichnen diese Umgebungen als DTAP, ein Akronym für Development, Test, Acceptance-test (oder Pre-Production) und Production. Ab hier wird der Text in Großbuchstaben geschrieben, um eine Umgebung zu kennzeichnen. Im Grunde ist es wie mit dem Testen selbst: Sie werden es nie zu 100 % hinbekommen, aber es wird Ihnen sehr helfen, wenn Sie in eine solide, wartbare DTAP investieren.

Das folgende Beispiel basiert grob auf der Situation bei einem unserer jüngsten Kunden. Das Unternehmen verfügt über eine ziemlich beeindruckende Reihe von Anwendungen und Diensten, die zusammen geschäftskritische Funktionen für verschiedene Arten von Endbenutzern implementieren. Das Backend besteht aus einer Vor-Web-Technologie, auf die über Webdienste zugegriffen wird. Die Backend-Anwendung ist etwa zehn Jahre alt und hatte in der Vergangenheit einige Probleme, ist jetzt aber recht stabil. Das Team hat einen Zeitplan für die Veröffentlichung entwickelt, den es für die Gewährleistung der Stabilität für unerlässlich hält. Alle drei Monate wird die neue Version nach strengen Tests in der Entwicklungsumgebung in den Testbetrieb gegeben. Von dort aus wird die Anwendung schließlich in die Produktion überführt. Das geht schon seit Jahren so.

Die Webteams haben ebenfalls eine Entwicklungsumgebung (die nicht auf ihren Desktops liegt), aber diese ist mit seltsamen Entwicklerdaten gefüllt, was sie für die Tester unbrauchbar macht. Also pflegen die Tester ihre Testdaten in den Testdatenbanken. Sie arbeiten alle in Scrum-Teams (im Gegensatz zum Backend-Team), so dass das Testen hier eine kontinuierliche Tätigkeit ist. Sie können sich inzwischen denken, wo das Problem liegt. Die Scrum-Tester müssen drei Monate warten, bis sie ihre Funktionen testen können, weil sie sehr stark vom Backend-System abhängig sind.

Außerdem gibt es eine Reihe von Anwenderberichten, die eine Interaktion mit externen Unternehmen erfordern. Die Netzwerkspezialisten haben beschlossen, dass ihre Firewalls nur in der Akzeptanzumgebung wirklich geöffnet werden. Erst nachdem also alle funktionalen Tests in der Testumgebung durchgeführt wurden und in einer Phase des Projekts, in der die ultimative Deadline näher rückt (Sie kennen den Deal, das Marketing hat bereits eine Radiokampagne gestartet, in der es heißt, dass die Website an diesem Tag völlig "neu und verbessert" sein wird), können Sie die B2B-Funktionen testen. Natürlich hat sich die gesamte Projektplanung als etwas zu optimistisch erwiesen, aber bis jetzt läuft alles ziemlich reibungslos.

Weniger als eine Woche vor der Live-Schaltung entdeckt jemand im Webteam, dass seine Anwendung in Acceptance tatsächlich mit der Sicherheitskomponente in Test verbunden ist. Akzeptanz und Produktion sind zu 100% identisch (so wie es sein sollte), aber der Test unterscheidet sich in unklarer Weise. Die Akzeptanzkomponente wurde also nie getestet. Jetzt gibt es plötzlich keine Garantie mehr, dass die Produktion funktioniert! Einen Tag später: noch mehr Entsetzen: Die Sicherheit in Test und Acceptance ist völlig unterschiedlich. In Acceptance funktioniert sie nicht! Sie können sich vorstellen, wie groß der Stress zu diesem Zeitpunkt war. Zum Glück geht die Geschichte gut aus, auch wenn es sie viel harte Arbeit gekostet hat.

Die Probleme bestehen auf verschiedenen Ebenen.

• Organisatorisch: Verschiedene Teams haben unterschiedliche Ansichten und Praktiken in Bezug auf die Testumgebungen. In diesem Beispiel führte dies dazu, dass die Tests zu spät durchgeführt wurden.
• Prozedural: Änderungen an den Umgebungen werden nicht ausgewertet und aufgezeichnet (oder nur in der Produktion). Sie werden Spaghetti haben!
• Bewusste Entscheidungen: Die Firewall-Richtlinie in unserem Beispiel. An sich nicht schlecht, führt aber zu späten Tests.
• Fehler: unerwartete oder falsche Verbindungen zwischen Komponenten in verschiedenen Testumgebungen.
• Dokumentationsschulden: das Fehlen einer angemessenen und aktuellen technischen Dokumentation (Diagramme).
• Nachlässigkeit: Änderungen in einer Umgebung werden nicht auf andere Umgebungen übertragen.
• Denkweise: "Dieser Fehler wird bei der Abnahme und Produktion wahrscheinlich nicht auftauchen". Dieser Glaube, der aus den bestehenden DTAP-Unterschieden herrührt, öffnet die Tür für Herrn Murphy, der mit Sicherheit den Raum betreten wird.
• Skalierungsunterschiede: Die Entwicklungsumgebung hat kein Clustering. Dies könnte später zu Fehlern führen, da die Anwendungen nicht geclustert werden können.

Je länger Unternehmen zulassen, dass DTAP-Probleme bestehen, desto schwieriger werden sie zu beheben sein. Das ist keine Raketenwissenschaft. Wahrscheinlich weiß das jeder in der IT, auch die verantwortlichen Manager. Es ist vielleicht etwas schwierig, es dem Finanzmann, dem Produktverantwortlichen oder dem Kunden zu erklären. Es ist wie beim Refactoring von Code. Sie werden erklären müssen, dass internes Housekeeping notwendig ist, um das nötige Budget zu erhalten.

Was ist also zu tun? Auch das ist keine Raketenwissenschaft. Der Hauptpunkt dieses Blogs ist, dass Sie sich bewusst machen müssen, dass Dinge falsch laufen und dass dies zu verzögerten Projekten, mehr Fehlern als nötig, steigendem Stresspegel, Frustration oder Ärger zwischen Entwicklern, Testern und Administratoren führt.

Einige Ratschläge:

• Drehen Sie an den richtigen (vielen) Knöpfen. Alle Änderungen müssen von einem Änderungsmanager genehmigt und koordiniert werden. Reproduzieren Sie die Änderungen. Dokumentieren Sie sie. Testen Sie die Testumgebung nach jeder Änderung.
• Halten Sie es einfach. Führen Sie nicht zu viele Unterschiede ein, um die Kosten zu senken. Das würde den Verwaltungsaufwand erhöhen. Erstellen Sie also diesen Cluster in Development, aber skalieren Sie auf eine geringere Anzahl von Clustermitgliedern.
• Bringen Sie Ihre Teams in Einklang. Sie müssen die Art und Weise, wie sie eine Testumgebung behandeln, teilen, einschließlich der Release-Zyklen.
• Seien Sie defensiv. Seien Sie pessimistisch. Pessimistische Menschen haben oft Recht. Der Fehler eines Administrators hat oft weitaus größere Auswirkungen als der eines Programmierers. Testen Sie alles.