Test Management and Coordination During the Vera C. Rubin Observatory Commissioning and Early Operations Using Zephyr Scale

Stellen Sie sich das Vera C. Rubin Observatory als ein riesiges, unglaublich komplexes Raumschiff vor, das auf einem Berg in Chile parkt. Seine Aufgabe ist es, Millionen von Fotos des Universums zu machen, um die ultimative Karte des Kosmos zu erstellen. Doch bevor es mit seiner eigentlichen Mission beginnen konnte, musste das Team es „in Betrieb nehmen“ (commissioning) – im Grunde mussten sie jeden einzelnen Knopf, jedes Drehrad und jede Kameralinse testen, um sicherzustellen, dass alles perfekt funktioniert.

Dieses Papier erzählt die Geschichte, wie ein Team aus über 50 Experten hunderte dieser Tests bewältigte, ohne den Verstand zu verlieren, indem sie ein digitales Werkzeug namens Zephyr Scale nutzten (das ursprünglich für das Testen von Software entwickelt wurde, nicht für riesige Teleskope).

Hier ist die Erklärung, wie sie es geschafft haben, unterteilt in einfache Konzepte:

1. Das Problem: Zu viele Köche, zu viele Rezepte

Stellen Sie sich vor, Sie versuchen, einen Restaurantbetrieb zu führen, bei dem 50 verschiedene Köche entscheiden wollen, was sie kochen, wann sie kochen und wie sie kochen – und das alles, während sich die Küche ständig verändert.

• Die Realität: Das Team des Observatoriums musste tägliche Änderungen, technische Störungen und neue wissenschaftliche Ziele koordinieren. Sie brauchten eine Möglichkeit, dem „Küchenpersonal“ (den Observing Specialists) jeden Abend genau zu sagen, was zu tun ist, und sie brauchten eine Möglichkeit, zu protokollieren, ob das Essen tatsächlich gut geschmeckt hat.
• Die Lösung: Sie führten Zephyr Scale ein. Betrachten Sie dies als ein digitales Rezeptbuch, das innerhalb einer Projektmanagement-App (Jira) lebt. Es war nicht für Teleskope konzipiert, aber das Team erkannte, dass es das perfekte Werkzeug war, um ihr Chaos zu organisieren.

2. Die drei Hauptzutaten

Das Papier beschreibt drei Schlüsselteile ihres Systems, die wir als das Rezept, das Tagesmenü und das Kochbuch-Protokoll betrachten können.

• Der Testfall (Das Rezept):
  Dies ist ein einzelner, wiederverwendbarer Anweisungssatz. Es ist wie ein Rezept für „Wie man einen Kuchen backt“. Es hat einen Titel, eine Liste von Schritten und ein festgelegtes Ergebnis.

  • Analogie: Wenn der Test darin besteht, „Das Teleskop auf einen Stern ausrichten und ein Foto machen“, dann ist der Testfall das schriftliche Rezept, das besagt: „Schritt 1: Motor einschalten. Schritt 2: 5 Sekunden warten. Schritt 3: Foto aufnehmen.“
  • Komplexität: Einige Rezepte sind einfach. Andere sind so komplex (mit hunderten von Schritten), dass sie als JSON BLOCKs gespeichert werden – denken Sie an diese als vorgefertigte, automatisierte Fertiggerichte, die der Computer einfach „einstecken“ und ausführen kann, ohne dass ein Mensch jedes einzelne Wort lesen muss.

• Der Testzyklus (Das Tagesmenü):
  Jeden Tag erstellt das Team einen neuen „Testzyklus“. Dies ist das Menü für den Abend. Er gruppiert alle spezifischen Rezepte (Test Cases), die an diesem Abend ausprobiert werden sollen.

  • Analogie: Genau wie ein Restaurant ein „Dienstags-Special“-Menü hat, hat das Observatorium einen „Dienstagabend-Testplan“.
  • Die Wendung: Oft planen sie mehr, als sie tatsächlich schaffen können. Manchmal fügen sie 30 Rezepte zum Menü hinzu, haben aber nur Zeit, 23 zu kochen. Das System verfolgt genau, was gekocht wurde und was im Regal stehen geblieben ist.

• Die Testausführung (Das Kochbuch-Protokoll):
  Wenn ein Mensch tatsächlich einen Schritt aus dem Rezept ausführt, markiert er diesen im System als erledigt. Dies erzeugt eine „Testausführung“ (Test Execution).

  • Analogie: Dies ist der Koch, der in ein Notizbuch schreibt: „Ich habe den Kuchen gebacken. Er ist perfekt aufgegangen. Ich habe extra viel Zucker hinzugefügt.“
  • Warum es wichtig ist: Selbst wenn das Rezept später geändert wird, bleibt dieses Protokoll in der Zeit eingefroren. Es beweist genau, was in dieser spezifischen Nacht passiert ist, was entscheidend für Wissenschaftler ist, die Jahre später nachvollziehen wollen, warum ein Foto auf eine bestimmte Weise entstanden ist.

3. Wie das Team zusammenarbeitete

Das Papier beschreibt einen sehr spezifischen Rhythmus ihres Tages, wie einen gut choreografierten Tanz:

1. Die Idee: Jemand hat eine neue Idee für einen Test (z. B. „Lassen Sie uns prüfen, wie die Kamera mit Hitze umgeht“).
2. Der Chat: Sie diskutieren dies auf Slack (einer Gruppenchat-App).
3. Die Formalisierung: Sie verwandeln diese Chat-Idee in einen formellen Testfall (ein Rezept) in Zephyr.
4. Die Überprüfung: Ein leitender Wissenschaftler überprüft das Rezept, um sicherzustellen, dass es sicher und klar ist.
5. Die Planung: Am nächsten Morgen schaut sich ein „Test Planner“ das Tagesmenü (Test Cycle) an und fügt die genehmigten Rezepte hinzu.
6. Die Ausführung: Die Observing Specialists (die Personen, die tatsächlich am Teleskop arbeiten) folgen dem Menü und haken die Schritte nach und nach ab.
7. Die wöchentliche Kontrolle: Einmal pro Woche trifft sich das gesamte Team, um zu entscheiden, was der „Geschmack der Woche“ sein soll. Konzentrieren wir uns darauf, ein defektes Teil zu reparieren? Oder konzentrieren wir uns darauf, mehr Bilder zu machen? Sie priorisieren basierend auf dem, was ihnen am meisten lehrt.

4. Das Gute, das Schlechte und das Hässliche

Die Autoren sind ehrlich über die Stärken und Schwächen des Werkzeugs.

Das Gute:

• Es schafft ein dauerhaftes Archiv: Im Gegensatz zu einem Stück Papier oder einem Whiteboard erinnert sich das System an jede Änderung. Wenn ein Rezept aktualisiert wurde, weiß das System genau, welche Version an welchem Abend verwendet wurde.
• Es verbindet die Punkte: Da es innerhalb von Jira lebt, verknüpft es den Test direkt mit den Fehlerberichten (Bug Reports) oder Engineering-Tickets, sodass jeder weiß, warum ein Test stattfindet.

Das Schlechte:

• Es ist etwas sperrig: Das Werkzeug wurde nicht für Teleskope gebaut, daher sind einige Funktionen nervig. Zum Beispiel ist es schwierig, zwei Versionen eines Rezepts nebeneinander zu vergleichen.
• Veraltete Informationen: Manchmal werden Notizen, die für eine Nacht geschrieben wurden, versehentlich in das Menü der nächsten Nacht kopiert, was das Personal verwirrt. Das Team muss diese jeden Tag manuell bereinigen.
• Link-Verlust (Link Rot): Wenn sich eine Version eines Rezepts ändert, bricht die Verknüpfung ab, was es schwierig macht, alte Anweisungen später wiederzufinden.

5. Das große Fazit

Das Papier kommt zu dem Schluss, dass Zephyr Scale zwar kein perfektes, maßgeschneidertes Werkzeug für ein riesiges Teleskop ist, es aber funktionierte, weil das Team diszipliniert war.

Sie behandelten die Software wie einen strengen Satz von Regeln:

• Wenn ein Rezept nicht als „Bereit“ markiert ist, kommt es nicht auf das Menü.
• Wenn ein Schritt nicht abgehakt wurde, ist er nicht passiert.

Die Autoren geben zu, dass sie erwarteten, dieses Werkzeug zu nutzen, sobald das Teleskop „in Betrieb genommen“ (commissioned) und reibungslos laufend wäre. Aber sie erkannten, dass sie es immer noch brauchen. Warum? Weil eine einfache Checkliste auf einer Website nicht skalierbar ist. Wenn man jeden Abend hunderte von Schritten abhaken muss, braucht man ein System, das automatisch für jede Nacht ein neues, sauberes Protokoll erstellt, damit man nie den Überblick darüber verliert, was passiert ist.

Kurz gesagt: Sie nahmen ein Werkzeug, das für Softwarefehler entwickelt wurde, und nutzten es, um eine riesige wissenschaftliche Maschine zu steuern – ein Beweis dafür, dass man mit genügend Disziplin und einem guten Workflow ein „quadratisches Loch“ sehr erfolgreich in ein „rundes Loch“ passen kann.