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

Immaginate l'Osservatorio Vera C. Rubin come una nave spaziale enorme e incredibilmente complessa parcheggiata su una montagna in Cile. Il suo compito è scattare milioni di foto dell'universo per creare la mappa definitiva del cosmo. Ma prima di poter iniziare la sua missione principale, il team ha dovuto "commettere" (mettere in servizio) la struttura — in sostanza, dovevano testare ogni singolo pulsante, manopola e lente della fotocamera per assicurarsi che funzionasse perfettamente.

Questo articolo racconta come un team di oltre 50 esperti sia riuscito a gestire centinaia di questi test senza perdere la ragione, utilizzando uno strumento digitale chiamato Zephyr Scale (che era stato originariamente costruito per testare il software, non telescopi giganti).

Ecco come ci sono riusciti, suddiviso in concetti semplici:

1. Il Probleo: Troppi cuochi, troppe ricette

Immaginate di cercare di gestire il servizio di una cena dove 50 chef diversi cercano di decidere cosa cucinare, quando cucinare e come cucinare, il tutto mentre la cucina cambia costantemente.

• La Realtà: Il team dell'osservatorio doveva coordinare cambiamenti quotidiani, problemi tecnici e nuovi obiettivi scientifici. Avevano bisogno di un modo per dire al "personale di cucina" (gli Specialisti dell'Osservazione) esattamente cosa fare ogni singola notte, e avevano bisogno di un modo per registrare se il cibo avesse effettivamente avuto un buon sapore.
• La Soluzione: Hanno adottato Zephyr Scale. Pensate a questo come a un libro di ricette digitale che vive all'interno di un'app di gestione dei progetti (Jira). Non era progettato per i telescopi, ma il team si è reso conto che era lo strumento perfetto per organizzare il proprio caos.

2. I tre ingredienti principali

L'articolo descrive tre parti chiave del loro sistema, che possiamo considerare come la Ricetta, il Menu del giorno e il Registro dello Chef.

• Il Caso di Test (La Ricetta):
  Questo è un insieme di istruzioni riutilizzabile. È come una ricetta per "Come preparare una torta". Ha un titolo, un elenco di passaggi e il risultato che dovrebbe ottenere.

  • Analogia: Se il test è "Puntare il telescopio verso una stella e scattare una foto", il Caso di Test è la ricetta scritta che dice: "Passaggio 1: Accendere il motore. Passaggio 2: Attendere 5 secondi. Passaggio 3: Scattare la foto".
  • Complessità: Alcune ricette sono semplici. Altre sono così complesse (che coinvolgono centinaia di passaggi) che vengono memorizzate come JSON BLOCK — pensate a questi come a kit di pasti pre-confezionati e automatizzati che il computer può semplicemente "inserire" ed eseguire senza che un essere umano debba leggere ogni singola parola.

• Il Ciclo di Test (Il Menu del giorno):
  Ogni giorno, il team crea un nuovo "Ciclo di Test". Questo è il menu per la serata. Raggruppa tutti i casi di test specifici (le ricette) che intendono provare quella sera.

  • Analogia: Proprio come un ristorante ha un menu per i "Speciali del Martedì", l'osservatorio ha un "Piano di Test del Martedì sera".
  • Il colpo di scena: Spesso pianificano più di quanto riescano effettivamente a fare. A volte aggiungono 30 ricette al menu ma hanno tempo solo per cucinarne 23. Il sistema traccia esattamente cosa è stato cucinato e cosa è rimasto sullo scaffale.

• L'Esecuzione del Test (Il Registro dello Chef):
  Quando un essere umano esegue effettivamente un passaggio di una ricetta, lo segna come completato nel sistema. Questo crea un' "Esecuzione del Test".

  • Analogia: Questo è lo chef che scrive in un taccuino: "Ho cotto la torta. È lievitata perfettamente. Ho aggiunto zucchero extra".
  • Perché è importante: Anche se la ricetta cambia in seguito, questo registro rimane congelato nel tempo. Dimostra esattamente cosa è successo in quella specifica notte, il che è fondamentale per gli scienziati che guarderanno indietro anni dopo per capire perché una foto è venuta in un certo modo.

3. Come lavorava il team

L'articolo descrive un ritmo molto specifico per la loro giornata, come una danza ben coreografata:

1. L'Idea: Qualcuno ha una nuova idea per un test (es. "Controlliamo se la fotocamera gestisce bene il calore").
2. La Chat: Ne discutono su Slack (un'app di chat di gruppo).
3. La Formalizzazione: Trasformano quell'idea della chat in un Caso di Test (una ricetta) formale in Zephyr.
4. La Revisione: Uno scienziato senior revisiona la ricetta per assicurarsi che sia sicura e chiara.
5. La Pianificazione: La mattina successiva, un "Pianificatore di Test" guarda il menu giornaliero (Ciclo di Test) e aggiunge le ricette approvate al programma.
6. L'Esecuzione: Gli Specialisti dell'Osservazione (le persone che si trovano effettivamente al telescopio) seguono il menu, spuntando i passaggi man mano che procedono.
7. Il Controllo Settimanale: Una volta a settimana, l'intero team si riunisce per decidere quale sarà il "gusto della settimana". Ci concentriamo sul riparare una parte rotta? O ci concentriamo sul fare più foto? Prioritizzano in base a ciò che insegnerà loro di più.

4. Il Bene, il Male e il Brutto

Gli autori sono onesti riguardo ai punti di forza e di debolezza dello strumento.

Il Bene:

• Crea un record permanente: A differenza di un pezzo di carta o di una lavagna, il sistema ricorda ogni modifica. Se una ricetta è stata aggiornata, il sistema sa esattamente quale versione è stata utilizzata in quale notte.
• Collega i punti: Poiché vive all'interno di Jira, collega il test direttamente ai report dei bug o ai ticket di ingegneria, in modo che tutti sappiano perché un test viene eseguito.

Il Male:

• È un po' macchinoso: Lo strumento non è stato costruito per i telescopi, quindi alcune funzioni sono fastidiose. Ad esempio, è difficile confrontare due versioni di una ricetta affiancate.
• Informazioni obsolete: A volte, note scritte per una notte vengono accidentalmente copiate nel menu della notte successiva, confondendo il personale. Il team deve pulirle manualmente ogni giorno.
• Link rotto (Link rot): Se una versione di una ricetta cambia, il collegamento si interrompe, rendendo difficile ritrovare le vecchie istruzioni in seguito.

5. La Grande Conclusione

L'articolo conclude che, sebbene Zephyr Scale non sia uno strumento perfetto e costruito su misura per un grande telescopio, ha funzionato perché il team è stato disciplinato.

Hanno trattato il software come un insieme rigoroso di regole:

• Se una ricetta non è contrassegnata come "Pronta", non va nel menu.
• Se un passaggio non è spuntato, non è avvenuto.

Gli autori ammettono che si aspettavano di smetere di usare questo strumento una volta che il telescopio fosse stato "commissionato" e funzionante regolarmente. Ma si sono resi conto che ne hanno ancora bisogno. Perché? Perché una semplice lista di controllo su un sito web non è scalabile. Quando devi spuntare centinaia di passaggi ogni notte, hai bisogno di un sistema che crei automaticamente un nuovo, pulito registro per ogni singola notte, in modo da non perdere mai traccia di ciò che è accaduto.

In breve: Hanno preso uno strumento progettato per i bug del software e lo hanno usato per gestire una gigantesca macchina scientifica, dimostrando che con abbastanza disciplina e un buon flusso di lavoro, si può far incastrare con successo un "pezzo quadrato" in un "buco rotondo".