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

कल्पना कीजिए कि वेरा सी. रुबिन ऑब्जर्वेटरी (Vera C. Rubin Observatory) चिली के एक पहाड़ पर खड़ी एक विशाल, अविश्वसनीय रूप से जटिल अंतरिक्ष यान (spaceship) है। इसका काम ब्रह्मांड की करोड़ों तस्वीरें लेना है ताकि ब्रह्मांड का एक अंतिम मानचित्र तैयार किया जा सके। लेकिन अपने मुख्य मिशन को शुरू करने से पहले, टीम को इसे "कमीशन" करना था—यानी, उन्हें इसके हर एक बटन, डायल और कैमरा लेंस का परीक्षण करना था ताकि यह सुनिश्चित हो सके कि यह पूरी तरह से काम कर रहा है।

यह शोध पत्र बताता है कि कैसे 50 से अधिक विशेषज्ञों की एक टीम ने अपने मानसिक संतुलन को खोए बिना सैकड़ों परीक्षणों को प्रबंधित किया, जिसके लिए उन्होंने ज़ेफ़र स्केल (Zephyr Scale) नामक एक डिजिटल टूल का उपयोग किया (जिसे मूल रूप से सॉफ्टवेयर परीक्षण के लिए बनाया गया था, न कि विशाल दूरबीनों के लिए)।

यहाँ बताया गया है कि उन्होंने यह कैसे किया, जिसे सरल अवधारणाओं में विभाजित किया गया है:

1. समस्या: बहुत सारे रसोइए, बहुत सारी रेसिपीज़

कल्पना कीजिए कि आप एक डिनर सर्विस चलाने की कोशिश कर रहे हैं जहाँ 50 अलग-अलग शेफ यह तय करने की कोशिश कर रहे हैं कि क्या पकाना है, कब पकाना है और कैसे पकाना है, और वह भी तब जब रसोई लगातार बदल रही हो।

• वास्तविकता: ऑब्जर्वेटरी टीम को दैनिक परिवर्तनों, तकनीकी गड़बड़ियों और नए वैज्ञानिक लक्ष्यों के साथ तालमेल बिठाना था। उन्हें "रसोई कर्मचारियों" (ऑब्जर्विंग स्पेशलिस्ट्स) को हर रात ठीक-ठीक बताने के लिए एक तरीके की आवश्यकता थी कि उन्हें क्या करना है, और उन्हें यह रिकॉर्ड करने के लिए भी एक तरीके की आवश्यकता थी कि क्या भोजन वास्तव में स्वादिष्ट बना।
• समाधान: उन्होंने ज़ेफ़र स्केल को अपनाया। इसे एक डिजिटल रेसिपी बुक के रूप में सोचें जो एक प्रोजेक्ट मैनेजमेंट ऐप (Jira) के भीतर रहती है। इसे दूरबीनों के लिए नहीं बनाया गया था, लेकिन टीम ने महसूस किया कि यह उनके बिखराव को व्यवस्थित करने के लिए एकदम सही उपकरण है।

2. तीन मुख्य सामग्रियां

यह पत्र उनके सिस्टम के तीन मुख्य भागों का वर्णन करता है, जिन्हें हम रेसिपी (Recipe), डेली मेनू (Daily Menu) और कुक'स लॉग (Cook's Log) कह सकते हैं।

• टेस्ट केस (रेसिपी):
  यह एक एकल, पुन: प्रयोज्य (reusable) निर्देश सेट है। यह "केक कैसे बेक करें" की रेसिपी की तरह है। इसमें एक शीर्षक, चरणों की एक सूची और परिणाम कैसा दिखना चाहिए, यह दिया होता है।

  • उपमा: यदि टेस्ट "तारे की ओर टेलीस्कोप को मोड़ना और फोटो लेना" है, तो टेस्ट केस वह लिखित रेसिपी है जो कहती है: "चरण 1: मोटर चालू करें। चरण 2: 5 सेकंड प्रतीक्षा करें। चरण 3: फोटो खींचें।"
  • जटिलता: कुछ रेसिपी सरल होती हैं। अन्य इतनी जटिल होती हैं (जिसमें सैकड़ों चरण शामिल होते हैं) कि उन्हें JSON BLOCKs के रूप में संग्रहीत किया जाता है—इन्हें आप पूर्व-पैकेज किए गए, स्वचालित 'मील किट' की तरह समझ सकते हैं जिन्हें कंप्यूटर बिना किसी इंसान द्वारा हर शब्द पढ़े, बस "प्लग इन" करके चला सकता है।

• टेस्ट साइकिल (डेली मेनू):
  हर दिन, टीम एक नया "टेस्ट साइकिल" बनाती है। यह उस रात के लिए मेनू है। यह उन सभी विशिष्ट रेसिपीज़ (टेस्ट केस) को एक साथ समूहबद्ध करता है जिन्हें वे उस शाम आज़माने की योजना बना रहे हैं।

  • उपमा: जैसे एक रेस्टोरेंट में "मंगलवार के विशेष व्यंजन" का मेनू होता है, वैसे ही ऑब्जर्वेटरी के पास "मंगलवार रात का टेस्ट प्लान" होता है।
  • ट्विस्ट: वे अक्सर उतना ही प्लान करते हैं जितना वे वास्तव में कर सकते हैं। कभी-कभी वे मेनू में 30 रेसिपी जोड़ देते हैं लेकिन उनके पास केवल 23 पकाने का समय होता है। सिस्टम ट्रैक करता है कि वास्तव में क्या पकाया गया और क्या शेल्फ पर ही रह गया।

• टेस्ट एक्जीक्यूशन (कुक'स लॉग):
  जब कोई इंसान रेसिपी के किसी चरण को वास्तव में करता है, तो वे सिस्टम में उसे 'किया हुआ' मार्क करते हैं। इससे एक "टेस्ट एक्जीक्यूशन" बनता है।

  • उपमा: यह शेफ द्वारा नोटबुक में लिखने जैसा है: "मैंने केक बेक किया। यह अच्छी तरह से फूल गया। मैंने अतिरिक्त चीनी डाली।"
  • यह क्यों महत्वपूर्ण है: भले ही बाद में रेसिपी बदल जाए, यह लॉग समय में जम जाता है। यह साबित करता है कि उस विशेष रात को वास्तव में क्या हुआ था, जो उन वैज्ञानिकों के लिए बहुत महत्वपूर्ण है जो वर्षों बाद यह समझने के लिए पीछे मुड़कर देखते हैं कि एक फोटो एक निश्चित तरीके से क्यों बनी।

3. टीम ने मिलकर कैसे काम किया

यह पत्र उनके दिन की एक बहुत ही विशिष्ट लय का वर्णन करता है, जैसे एक सुव्यवस्थित नृत्य:

1. विचार: किसी के पास एक नए टेस्ट के लिए एक नया विचार है (जैसे, "आइए देखें कि कैमरा गर्मी को कैसे संभालता है")।
2. चैट: वे इस विचार पर Slack (एक ग्रुप चैट ऐप) पर चर्चा करते हैं।
3. औपचारिकता: वे उस चैट विचार को ज़ेफ़र में एक औपचारिक टेस्ट केस (एक रेसिपी) में बदलते हैं।
4. समीक्षा: एक वरिष्ठ वैज्ञानिक रेसिपी की समीक्षा करता है ताकि यह सुनिश्चित हो सके कि यह सुरक्षित और स्पष्ट है।
5. योजना: अगली सुबह, एक "टेस्ट प्लानर" दैनिक मेनू (टेस्ट साइकिल) को देखता है और स्वीकृत रेसिपीज़ को उसमें जोड़ता है।
6. निष्पादन (Execution): ऑब्जर्विंग स्पेशलिस्ट्स (जो वास्तव में टेलीस्कोप पर मौजूद हैं) मेनू का पालन करते हैं, और जैसे-जैसे वे कदम पूरे करते हैं, उन्हें टिक करते जाते हैं।
7. साप्ताहिक जाँच: सप्ताह में एक बार, पूरी टीम बैठक करती है ताकि यह तय किया जा सके कि इस सप्ताह का "फ्लेवर" क्या होना चाहिए। क्या हमें एक खराब हिस्से को ठीक करने पर ध्यान देना चाहिए? या हमें अधिक तस्वीरें लेने पर ध्यान देना चाहिए? वे प्राथमिकता के आधार पर निर्णय लेते हैं कि इससे उन्हें सबसे अधिक क्या सीखने को मिलेगा।

4. अच्छा, बुरा और बदतर

लेखक इस टूल की खूबियों और कमियों के बारे में ईमानदार हैं।

अच्छा:

• यह एक स्थायी रिकॉर्ड बनाता है: कागज के टुकड़े या व्हाइटबोर्ड के विपरीत, सिस्टम हर बदलाव को याद रखता है। यदि कोई रेसिपी अपडेट की गई थी, तो सिस्टम जानता है कि किस रात कौन सा संस्करण उपयोग किया गया था।
• यह कड़ियों को जोड़ता है: क्योंकि यह Jira के अंदर रहता है, यह टेस्ट को सीधे बग रिपोर्ट या इंजीनियरिंग टिकटों से जोड़ देता है, जिससे सभी को पता चलता है कि टेस्ट क्यों किया जा रहा है।

बुरा:

• यह थोड़ा बोझिल (clunky) है: यह टूल दूरबीनों के लिए नहीं बनाया गया था, इसलिए कुछ फीचर्स परेशान करने वाले हैं। उदाहरण के लिए, दो रेसिपी वर्ज़न की तुलना आमने-सामने करना कठिन है।
• पुरानी जानकारी: कभी-कभी, एक रात के लिए लिखे गए नोट्स गलती से अगली रात के मेनू में कॉपी हो जाते हैं, जिससे स्टाफ भ्रमित हो जाता है। टीम को हर दिन इन्हें मैन्युअल रूप से साफ करना पड़ता है।
• लिंक रॉट (Link rot): यदि किसी रेसिपी का वर्ज़न बदल जाता है, तो उसका लिंक टूट जाता है, जिससे बाद में पुराने निर्देशों को खोजना मुश्किल हो जाता है।

5. मुख्य निष्कर्ष

शोध पत्र निष्कर्ष निकालता है कि हालांकि ज़ेफ़र स्केल एक आदर्श, कस्टम-निर्मित टूल नहीं है जो एक विशाल टेलीस्कोप के लिए बना हो, फिर भी यह काम कर गया क्योंकि टीम अनुशासित थी।

उन्होंने सॉफ्टवेयर के साथ एक सख्त नियमों वाली व्यवस्था की तरह व्यवहार किया:

• यदि रेसिपी को "रेडी" के रूप में मार्क नहीं किया गया है, तो वह मेनू में नहीं जाएगी।
• यदि किसी चरण को चेक (check off) नहीं किया गया है, तो वह हुआ ही नहीं।

लेखक स्वीकार करते हैं कि उन्हें उम्मीद थी कि एक बार जब टेलीस्कोप "कमीशन" हो जाएगा और सुचारू रूप से चलने लगेगा, तो वे इस टूल का उपयोग करना बंद कर देंगे। लेकिन उन्हें एहसास हुआ कि उन्हें अभी भी इसकी आवश्यकता है। क्यों? क्योंकि वेबसाइट पर एक साधारण चेकलिस्ट किसी चीज़ का पैमाना (scale) नहीं हो सकती। जब आपको हर रात सैकड़ों चरणों को चेक करना होता है, तो आपको एक ऐसे सिस्टम की आवश्यकता होती है जो स्वचालित रूप से हर रात के लिए एक नया, साफ लॉग बना सके, ताकि आप कभी भी यह ट्रैक न खोएं कि क्या हुआ था।

संक्षेप में: उन्होंने एक ऐसे टूल को लिया जिसे सॉफ्टवेयर बग्स के लिए बनाया गया था और उसका उपयोग एक विशाल वैज्ञानिक मशीन चलाने के लिए किया, यह साबित करते हुए कि पर्याप्त अनुशासन और एक अच्छे वर्कफ़्लो के साथ, आप एक "चौकोर खूंटे को गोल छेद में" सफलतापूर्वक फिट कर सकते हैं।