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

Stel je de Vera C. Rubin Observatory voor als een enorm, ongelooflijk complex ruimteschip dat geparkeerd staat op een berg in Chili. Zijn taak is om miljoenen foto's van het universum te maken om de ultieme kaart van het kosmos te creëren. Maar voordat hij aan zijn hoofdmissie kon beginnen, moest het team hem "commissioneren"—in essentie moesten ze elke knop, draaiknop en cameralens testen om te controleren of alles perfect werkte.

Dit artikel vertelt het verhaal van hoe een team van meer dan 50 experts honderden van deze tests beheerde zonder hun verstand te verliezen, met behulp van een digitale tool genaamd Zephyr Scale (die oorspronkelijk werd gebouwd voor het testen van software, niet voor gigantische telescopen).

Dit is hoe ze het deden, onderverdeeld in eenvoudige concepten:

1. Het Probleem: Te Veel Koks, Te Veel Recepten

Stel je voor dat je een dinerbediening probeert te runnen waarbij 50 verschillende chefs proberen te beslissen wat er gekookt wordt, wanneer het gekookt wordt en hoe het gekookt moet worden, terwijl de keuken constant verandert.

• De Realiteit: Het team van het observatorium moest dagelijkelijk omgaan met veranderingen, technische problemen en nieuwe wetenschappelijke doelen. Ze hadden een manier nodig om de "keukenstaf" (de Observing Specialists) precies te vertellen wat ze elke avond moesten doen, en ze hadden een manier nodig om vast te leggen of het eten daadwerkelijk lekker smaakte.
• De Oplossing: Ze adopteerden Zephyr Scale. Zie dit als een digitale receptenboek dat leeft binnen een projectmanagementapp (Jira). Het was niet ontworpen voor telescopen, maar het team realiseerde zich dat het de perfecte tool was om hun chaos te organiseren.

2. De Drie Belangrijkste Ingrediënten

Het artikel beschrijft drie belangrijke onderdelen van hun systeem, die we kunnen zien als het Recept, het Dagmenu en het Logboek van de Kok.

• De Test Case (Het Recept):
  Dit is een enkele, herbruikbare instructieset. Het is als een recept voor "Hoe bak je een cake". Het heeft een titel, een lijst met stappen en een beschrijving van wat het resultaat moet zijn.

  • Analogie: Als de test is "Richt de telescoop op een ster en maak een foto", dan is de Test Case het geschreven recept dat zegt: "Stap 1: Zet de motor aan. Stap 2: Wacht 5 seconden. Stap 3: Maak een foto."
  • Complexiteit: Sommige recepten zijn eenvoudig. Anderen zijn zo complex (met honderden stappen) dat ze worden opgeslagen als JSON BLOCKs—denk aan deze als vooraf verpakte, geautomatiseerde maaltijdkits die de computer simpelweg kan "pluggen" en uitvoeren zonder dat een mens elk woord hoeft te lezen.

• De Test Cycle (Het Dagmenu):
  Elke dag maakt het team een nieuwe "Test Cycle" aan. Dit is het menu voor de avond. Het groepeert alle specifieke recepten (Test Cases) die ze die avond van plan zijn uit te proberen.

  • Analogie: Net zoals een restaurant een "Dinsdag Specials" menu heeft, heeft het observatorium een "Dinsdagavond Testplan".
  • De Twist: Ze plannen vaak meer dan ze daadwerkelijk kunnen doen. Soms voegen ze 30 recepten toe aan het menu, maar hebben ze maar tijd om er 23 te koken. Het systeem houdt precies bij welke gerechten zijn gekookt en wat er nog in de schappen lag.

• De Test Execution (Het Logboek van de Kok):
  Wanneer een mens daadwerkelijk een stap uit het recept uitvoert, vinken ze deze in het systeem af. Dit creëert een "Test Execution".

  • Analogie: Dit is de chef die in een schriftje schrijft: "Ik heb de cake gebakken. Hij is goed gerezen. Ik heb extra suiker toegevoegd."
  • Waarom het belangrijk is: Zelfs als het recept later verandert, blijft dit logboek bevroren in de tijd. Het bewijst precies wat er op die specifieke avond is gebeurd, wat cruciaal is voor wetenschappers die jaren later willen begrijpen waarom een foto op een bepaalde manier tot stand kwam.

3. Hoe het Team Samenwerkte

Het artikel beschrijft een zeer specifieke ritme in hun dag, als een goed choreografische dans:

1. Het Idee: Iemand heeft een nieuw idee voor een test (bijv. "Laten we controleren of de camera goed met warmte omgaat").
2. De Chat: Ze bespreken het op Slack (een groepschat-app).
3. De Formalisering: Ze veranderen dat chat-idee in een formele Test Case (een recept) in Zephyr.
4. De Review: Een senior wetenschapper beoordeelt het recept om te controleren of het veilig en duidelijk is.
5. De Planning: De volgende ochtend kijkt een "Test Planner" naar het dagmenu (Test Cycle) en voegt de goedgekeurde recepten toe aan het menu.
6. De Executie: De Observing Specialists (de mensen die daadwerkelijk bij de telescoop staan) volgen het menu en vinken stappen af terwijl ze bezig zijn.
7. De Wekelijkse Check: Eén keer per week komt het hele team samen om te beslissen wat de "smaak van de week" moet zijn. Moeten we ons richten op het repareren van een defect onderdeel? Of moeten we ons richten op het maken van meer foto's? Ze prioriteren op basis van wat hen het meeste zal leren.

4. Het Goede, het Slechte en het Lelijke

De auteurs zijn eerlijk over de sterke en zwakke punten van de tool.

Het Goede:

• Het creëert een permanent verslag: In tegenstelling tot een stuk papier of een whiteboard, onthoudt het systeem elke wijziging. Als een recept werd bijgewerkt, weet het systeem precies welke versie op welke nacht werd gebruikt.
• Het legt de verbanden: Omdat het binnen Jira leeft, koppelt het de test direct aan de bugrapporten of engineering-tickets, zodat iedereen weet waarom een test plaatsvindt.

Het Slechte:

• Het is een beetje onhandig: De tool was niet gebouwd voor telescopen, dus sommige functies zijn irritant. Bijvoorbeeld, het is lastig om twee versies van een recept naast elkaar te vergelijken.
• Verouderde informatie: Soms worden notities die voor de ene avond zijn geschreven, per ongeluk gekopieerd naar het menu van de volgende avond, wat het personeel in verwarring brengt. Het team moet deze elke dag handmatig opschonen.
• Link rot: Als een recept van versie verandert, verbreekt de link, waardoor het moeilijk wordt om oude instructies later terug te vinden.

5. De Belangrijkste Conclusie

Het artikel concludeert dat hoewel Zephyr Scale geen perfecte, op maat gemaakte tool is voor een gigantische telescoop, het werkte omdat het team gedisciplineerd was.

Ze behandelden de software als een strikte set regels:

• Als een recept niet als "Klaar voor gebruik" is gemarkeerd, komt het niet op het menu.
• Als een stap niet is afgevinkt, is deze niet uitgevoerd.

De auteurs geven toe dat ze verwachtten te stoppen met het gebruik van deze tool zodra de telescoop "gecommissioneerd" en draaiende was. Maar ze realiseerden zich dat ze het nog steeds nodig hebben. Waarom? Omdat een simpele checklist op een website niet schaalbaar is. Wanneer je elke avond honderden stappen moet afvinken, heb je een systeem nodig dat automatisch voor elke avond een nieuw, schoon logboek aanmaakt, zodat je nooit de draad kwijtraakt van wat er is gebeurd.

Kortom: Ze namen een tool die bedoeld was voor softwarebugs en gebruikten die om een gigantische wetenschappelijke machine aan te sturen, waarmee ze bewezen dat je met genoeg discipline en een goede workflow een "vierkant blokje" succesvol in een "rond gat" kunt passen.