7 Tipps für eine integrierte Testumgebung

Wie bekomme ich meine Systeme inklusive Testdaten auf Knopfdruck bereitgestellt?

Integrierte Testumgebungen? Wie bekommst du alle relevanten Systeme angebunden und mit den passenden Testdaten ausgestattet. Egal, ob DevOps, SCRUM, KANBAN oder ganz klassisch. Hier bekommst du 7 Tipps von mir, die dir dabei helfen, damit es auch mal schnell gehen kann!

Bestellung einer integrierten Testumgebung

Wie bekomme ich eine Testumgebung - aus Anforderer Sicht

Mal angenommen du hast eine zentrale Serviceeinheit, die dir eine integrierte Testumgebung auf Knopfdruck zur Verfügung stellen kann. Welche Informationen musst du für eine Bestellung noch beisteuern?

Systeme
Welche Anwendungen und Systeme müssen an deine Anwendung angeschlossen werden? Welche benötigst du um deine Testaufgaben zu erledigen?
Testdaten
Welche Testdaten benötigst du, damit du deine Tests durchführen kannst? Hast du auch Anforderungen an die integrierten Systeme? Wieviele Datensätze müssen vorhanden sein?
Szenarien
Welche Testszenarien möchtest du über die Systemgrenzen hinweg durchführen? Wie müssen die Systeme dafür vorbereitet sein?
dauer
Wie lange benötigst du die integrierte Umgebung? Dauerhaft? Wieviele Resets (Zurücksetzen) der Testdaten sind nötig?

Häufige Herausforderungen

Murphys Law - was schief gehen kann, geht schief!

Das sind nur einige der Stolpersteine, die dir begegnen können und werden. Wenn du Glück hast, hat die Herausforderung schon jemand angenommen und du kannst jetzt einfach nur deine Umgebung bestellen und dich zurücklehnen. Für die anderen habe ich 7 Tipps parat.

Meine 7 Tipps für eine integrierte Testumgebung

Dies ist wohl eines der wichtigsten Kapitel in deinem Testkonzept oder deiner Test Charta: Testumgebung(en). Wieviele benötigst du und wie bekommst du diese? Idealerweise so wie oben beschrieben – einfach anfordern. Damit dies auch bei dir schnell und einfach klappt, hier meine 7 Tipps! Für alle Tipps gilt übrigens meine Empfehlung dies als zentralen Service in einem Unternehmen aufzubauen. Die notwendigen Arbeiten können und sollen gerne von den Anwendungsteams übernommen werden, aber ein oder zwei Personen mit Überblickswissen sollten für eine solche Aufgabe schon vorgesehen werden.

Das fehlende Wissen muss sukzessive aufgebaut werden. Im Projektkontext kannst du dich darum kümmern, das von dir benötigte Umfeld zu beleuchten und deine Anforderung zu formulieren.

  • Wo kommen die Daten ursprünglich her und durch welche Systeme müssen sie verarbeitet werden?
  • Wie relevant ist das jeweilige System für dich?
  • Welche Abhängigkeiten bestehen zwischen den Systemen und welche kannst du ignorieren?
  • Wer sind die Ansprechpartner für die Systeme? Gibt es einen Service Owner oder einen Anwendungsbetreuer?

 

Zu jeder Anwendung solltest du deine Systemschnittstellen kennen. Auf dieser Basis bekommst du zumindest schon das minimale Set an Systemen, das du bewerten musst. Mit der Zeit wirst du herausfinden, was noch fehlt.

Je realistischer deine Testdaten sind, desto höher ist auch die Aussagekraft deiner Tests. Es kann aber auch sein, dass es sich um sehr einfache Schnittstellen handelt und du nur einfache Rückmeldungen benötigst.

Ich rate dir dazu, jedes System mit den dafür relevanten Testdaten aufzubauen. Das könnten z.B. Produktivabzüge sein, die zu der Softwareversion der dazugehörigen Anwendung passen. Das können auch automatisiert errichtete Daten sein, die du im Vorfeld explizit angefordert hast.

Wichtig ist dabei nur, dass je nach Vorgehen ein effizientes und ausreichendes Verfahren definiert, ausprobiert und umgesetzt wird, denn die Testdaten müssen meist über Systemgrenzen hinweg zusammenpassen. Dies kann und sollte bereits beim Deploymentprozess der Anwendung berücksichtigt werden.

Für jedes System stell sich dabei die Frage nach den relevanten Daten. Kannst Du diese aus einer Produktivumgebung mit allen relationalen Beziehungen abziehen, verändern und in deine Testumgebung einspielen? Kannst du dabei Datensätze replizieren (also nicht nur einen Max Mustermann, sondern gleich mehrere daraus generieren)?

Gerade bei der Datenmanipulation gibt es viele Anforderungen, um zu synthetischen Testdaten zu kommen. Die Anonymisierung ist dabei sicher eine der wichtigsten. Sind deine Testdaten DSGVO konform?

Wie findest Du geeignete Testdaten oder welche Informationen musst du für eine Testdatenanforderung liefern? Ich könnte über dieses Thema Romane schreiben, aber du würdest beim Lesen einschlafen. Darum kurz und knapp: neben dem Know-How zur jeweiligen Anwendung gibt es Tools, die wie ein Schweizer Taschenmesser sehr viele Funktionen für dich mitbringen. Hier kann ich dir benerator.de empfehlen.

Wenn du bei deiner Bewertung herausgefunden hast, dass du das System nicht als Testsystem zur Verfügung stellen kannst oder musst, aber trotzdem Input für deine Anwendung benötigst, kann ein Mock oder ein Mockservice deine Lösung sein. Hierbei solltest du zwischen einem anwendungsspezifischen und einem zentralen Mocksystem abwägen.

  • Anwendungsspezifischer Mock
    Der Mock wird speziell für eine Anwendung gebaut. Meist ist es das sendende System. Aber auch das empfangende Systeme kann einen Mock bauen, der alle relevanten  Schnittstellen mit einer wie auch immer benötigten Antwort bedient. Manchmal werden auch beide gebaut.
  • Zentrales Mocksystem
    Hast du eine sehr komplexe Systemlandschaft? Musst du viele Testdaten über die Testumgebung synchron halten? Dann kann auch ein zentrales Mocksystem zur Nutzung durch mehrere Testumgebungen Sinn machen.
 
Mocks werden häufig im Zuge der Entwicklung erstellt und genutzt. Werden diese mit korrekten Testdaten versorgt und kannst du das beeinflussen, reicht das vielleicht schon für deine notwendigen Tests. Vorsicht ist geboten bei Schnittstellenänderungen, denn dann muss ein Mock entsprechend angepasst werden. Rechtzeitig! Denn sonst wägst du dich in Sicherheit.

 

Ein zentrales Mocksystem kann aber auch mit Tools aufgebaut werden. Diese Tools können dann Testdaten aus Datenbanken generieren und mit allen möglichen Funktionen glänzen. Manche sind sehr teuer, manche kostenlos. Betreibst du hier Aufwand, solltest du sicherstellen, dass das Know-How nicht verloren geht und der Mock/Mockservice von jemandem betreut wird.

Jedes der Systeme muss auch betreut werden. Wer hilft bei Problemen oder Fragen weiter? Wer kann das System für den Test bedienen? Wer kann das System mit der passenden Version deployen? Und wer überwacht das System, ob es stabil läuft? Das kannst du alles in einem zentralen Service ansiedeln, aber der Systemowner sollte bei Bedarf verfügbar sein.

Für den Systemowner ist dies auch eine gute Möglichkeit neue Verfahren auszuprobieren oder neue Kollegen einzuarbeiten.

Deine Know-Howträger sind meist wertvolle Ressourcen, die nicht für häufig wiederkehrende Arbeiten gebunden sein sollten. Deshalb empfiehlt es sich, alle Aufgaben rund um die Bereitstellung so gut wie möglich zu automatisieren. Neben dem Anwendungsdeployment kann und sollte dies auch die Testdaten umfassen. Achte dabei auf kurze Laufzeiten, denn die Bereitstellungszeit sollte zu kurz wie möglich sein.

Achte auch darauf, dass Testdaten evtl. auch erweitert werden müssen. Wäre es nicht gut “mal eben” noch einen weiteren Max Mustermann hinzuzufügen? Hast du auch an Backup und Restore gedacht? Schnell eben zurücksetzen? Oder mal eben 100.000 Datensätze für einen Lasttest?

Es gibt nie genug Systeme! Auch in Zeiten von Cloudinfrastruktur wird es natürlich grenzen geben. Eine Skalierung muss deshalb nicht mit beliebig viel Systemressourcen, sondern kann auch logisch über Datentrennung erfolgen. Umso wichtiger ist es, dass du die Testdaten im Griff hast und diese beliebig erweitern kannst. Dein Tolling sollte auf jeden Fall in alle Richtungen skalierbar sein.

Egal wie du es anstellst – Murphys Law ist nicht weit. Je komplexer deine Systemabhängigkeiten sind, desto realistischer muss deine Testumgebung aufgebaut werden. Bist du unabhängig von allen anderen Systemen und ohne Schnittstellen, dann kannst du die Tipps für deine eigene Anwendung nutzen.

Ich habe häufig die Limitierung von notwendigen Systemen erlebt und wusste mir immer zu helfen. Ich hoffe die Tipps helfen dir bei deinen Herausforderungen! Wenn du mehr Impulse brauchst, dann melde dich bei mir.

Meine 7 Tipps für agiles Testen

Im Rahmen einiger Projekte, die nach SCRUM, KANBAN aber vor allem auch Mischformen von klassisch und agil sehr gut funktioniert haben, kann ich dir ein paar Hinweise geben, worauf du achten solltest.

Ich habe dein interesse geweckt?

Dann nutze jetzt die Gelegenheit und nimm Kontakt zu mir auf!