Was ein SRE-Agent für Tester leisten kann

Ich habe unzählige Stunden damit verschwendet, Bugs zu melden, mich zu ärgern, die Entwickler anzuschreiben, sie nachforschen zu lassen,... nur um herauszufinden, dass die Testumgebung kaputt war. Oder der falsche Branch deployt wurde. Oder die Testdaten veraltet waren...

Sehe ich überhaupt etwas, das stabil genug ist, um meinen eigenen Ergebnissen zu trauen? Die automatisierten Checks helfen bei vielem, greifen aber oft zu kurz, sobald es um die Infrastruktur geht.

Die Arbeit eines Testers hat sich über die letzten Jahrzehnte vielleicht gewandelt, doch nichts hat den klugen, forschenden und auf realen Belegen beruhenden Umgang eines erfahrenen Menschen mit der Software ausreichend ersetzt.

Kein "Herumklicken", wie es manche noch immer karikieren, sondern eine bewusste, fachkundige Untersuchung, bei der Lernen, Testentwurf und Ausführung gleichzeitig stattfinden. Und wenn Sie das mit risikobasiertem Denken verbinden, entsteht etwas Starkes: eine fokussierte Sitzung, in der jede Minute zählt, weil Sie wissen, warum Sie genau dort hinschauen.

Bei Hyground bauen wir einen SRE-Agenten, der in Produktivumgebungen lebt und atmet, sich aber auch an Entwicklungs- und Testumgebungen anbinden lässt.

Wenn ich sehe, über welche beeindruckenden Fähigkeiten und Einblicke er verfügt, denke ich an meine früheren Erfahrungen als Tester zurück.

Vor einigen Jahren wurde ich zu einem Projekt hinzugeholt, das, vorsichtig formuliert, unter Belagerung stand. Das Entwicklungsteam hatte sich verdoppelt. Neben dem zentralen Neuaufbau waren zwei weitere Projekte gestartet. Und die Software, eine vollständige Neuentwicklung eines Altsystems mit moderner Technologie, wurde schneller deployt, als irgendjemand prüfen konnte, was tatsächlich darin steckte.

Bugs vermehrten sich schneller, als Fix-Releases sie eindämmen konnten. Irgendwann habe ich sie sogar ausgedruckt und an die Wand geklebt, damit das Management sie nicht ignorieren konnte.

Was es wirklich schmerzhaft machte: Die Bugs, die wir fanden, waren nicht immer Bugs. Der falsche Build war deployt worden. Andere Male waren Daten zwischen den Testzyklen veraltet oder entfernt worden. Features, die seit unserem letzten Blick darauf überarbeitet worden waren. Wir steckten enorm viel Energie in die Untersuchung von Dingen, die gar keine Produktfehler waren. Schlimmer noch: Unsere Fragen verwirrten die Entwicklungsteams und kosteten auch sie Zeit.

... am Ende haben wir das Projekt zum Erfolg geführt, aber es war schmerzhaft. Hätten wir damals nur ein System wie Hyground gehabt.

Ich denke dieser Tage oft an dieses Projekt. Denn die Situation, für die es steht: rasante Änderungen, zu viele PRs, um den Überblick zu behalten, eine Umgebung, in der man der Stabilität dessen, was man testet, nicht trauen kann,... Nun, das ist heute Alltag.

Da KI-generierter Code das Entwicklungstempo beschleunigt, wird genau das zum Normalfall.

Hyground, ein KI-SRE-Agent, ist an Ihre Infrastruktur, Observability und mehr angebunden. In meinem früheren Projekt wäre er ein echter Retter gewesen, und für Tester ist er heute ein Lebensretter.

Was hat sich geändert?

Ob Sie einen KI-Agenten auf einer Plattform testen, ein Produkt ohne KI oder irgendetwas dazwischen: Die Wahrscheinlichkeit ist hoch, dass sich Ihr Produkt seit mindestens letztem Dezember in unglaublichem Tempo verändert.

Ständige und drastische Veränderung. Zwischen einer Testsitzung und der nächsten kann sich alles komplett verschieben. Neuer Code gemergt, Daten migriert, Infrastruktur angepasst, Features überarbeitet. Und niemand hat Ihnen genau gesagt, was sich geändert hat. Sie starten eine Sitzung mit den Annahmen der letzten Woche und stellen fest, manchmal erst nach mehreren gemeldeten Bugs, dass diese nicht mehr stimmen.

Für jeden Tester, der sich einer stark in Entwicklung befindlichen Umgebung nähert, sollte einer der ersten Gedanken der Umgebung selbst gelten. Was hat sich seit meinem letzten Blick geändert? Sind die Änderungen, die ich sehe, beabsichtigt oder versehentlich? Sind diese Daten frisch oder veraltet?

Ein SRE-Agent, der die Umgebung laufend überwacht, könnte das beantworten, noch bevor Sie Ihre Sitzung überhaupt beginnen. Er kann ein reales Bild zeichnen: Diese Services wurden neu deployt, diese Datenpipeline lief (oder eben nicht), diese Infrastrukturkomponenten haben ihre Konfiguration geändert. Genau die Art von Lageüberblick, für die wir Stunden an Slack-Nachrichten und Rätselraten brauchten.

Im allerbesten Fall mussten wir "diese eine Person fragen", und die war meist ziemlich beschäftigt.

Bin ich auf Erfolg eingestellt?

In diesem Projekt habe ich erlebt, wie erfahrene Tester ganze halbtägige Sitzungen damit verschwendeten, Dinge zu untersuchen, die sich als Inkonsistenzen der Umgebung herausstellten. Keine Bugs. Keine Design-Probleme. Nur die Trümmer einer Codebasis, die sich schneller bewegte, als ihr Integrationsprozess verkraften konnte. Diese Sitzungen waren verloren und führten zu viel verschwendeter Zeit und zusätzlichem Frust.

Bevor ich heute eine explorative Sitzung beginne, will ich Folgendes wissen:

• Ist diese Umgebung in einem gesunden Zustand?
• Welche PRs sind deployt?
• Laufen irgendwelche Drittanbieter-Prozesse?
• Sind die nachgelagerten Services erreichbar und gesund?
• Gibt es offene Jira-Issues, die auf bekannte Probleme mit dieser Umgebung hinweisen?
• Wie hoch ist die aktuelle Fehlerrate in den Logs?

... oder ich könnte einfach eine E-Mail an Hyground schicken: "Hey Hyground, ich möchte eine Testsitzung zu X in Umgebung Y durchführen. Gibt es etwas Ungewöhnliches, das ich wissen sollte?"

Genau hier verändert etwas wie Hyground das Spiel. Ein SRE-Agent, der Ihnen sagen kann "Ihr Kubernetes-Cluster ist gesund, aber dieser Service wurde vor 20 Minuten neu deployt und hat sich noch nicht stabilisiert", erspart Ihnen die Jagd nach Phantomen. Er macht aus einem Ratespiel ein Briefing.

Warum das jetzt wichtig ist

Das Projekt, das ich eingangs beschrieben habe, war für seine Zeit nicht ungewöhnlich. Ein Team, das sich so schnell bewegt, mit so viel Veränderung und so wenig Stabilität der Umgebung, fühlte sich extrem an, war aber wohl normaler, als wir zugeben möchten. Wir behalfen uns mit bunten Zetteln an der Wand und dem guten Willen von zwanzig engagierten Teammitgliedern.

Heute ist dieses Tempo normal. KI-gestützte Entwicklung bedeutet mehr PRs, häufigere Deployments, mehr Veränderung. Die Frage des Testers, "kann ich dem trauen, was ich vor mir sehe?", verschärft sich, statt nachzulassen.

Risikobasiertes exploratives Testen gibt Ihnen einen Rahmen, um Ihre begrenzte Zeit auf das Wichtigste zu konzentrieren. Es funktioniert aber nur, wenn die Umgebung mitspielt, oder wenn Sie das Werkzeug haben, um zu erkennen, wann sie es nicht tut. Genau dieses Stück fehlte vor Jahren in meinem Projekt. Es ist das Stück, das ich heute mit aufbaue.