बग-फ्री कोड गलत लक्ष्य है। यह रहा एक बेहतर लक्ष्य।

बग-फ्री कोड गलत लक्ष्य क्यों है

हर सिस्टम में ऐसे डिफेक्ट होते हैं जिन तक अभी कोई पहुँचा ही नहीं है, और जैसे-जैसे साफ़ दिखने वाले डिफेक्ट हटते जाते हैं, अगला ढूँढ़ने की लागत तेज़ी से चढ़ती जाती है। एक हद के बाद, डिफेक्ट खोजने में लगाया गया अतिरिक्त एक घंटा उसी एक घंटे से कम कीमती होता है जो फेलियर को सस्ते में पकड़ने और ठीक करने लायक बनाने में लगे।

दूसरी समस्या सांस्कृतिक है। जब घोषित लक्ष्य बग-फ्री होना हो, तो बग ऐसी जानकारी नहीं रह जाता जिस पर कार्रवाई की जाए, बल्कि एक नाकामी बन जाता है जिसकी सफ़ाई देनी पड़ती है — और लोग उनके बारे में चुप रहने लगते हैं।

तीन लक्ष्य जो सचमुच काम करते हैं

पहला लक्ष्य सबसे ज़्यादा मायने क्यों रखता है

जो टीम एक ही बग दो बार शिप नहीं करती, वह अपने ढाँचे की वजह से हर महीने बेहतर होती जाती है। इसके लिए ठीक एक आदत चाहिए: जब कुछ ठीक करें, तो पीछे एक जाँच छोड़ दें। ज़्यादातर टीमें बग ठीक करती हैं, टिकट बंद करती हैं, और कहीं यह दर्ज नहीं रहता कि उस व्यवहार को कभी सुरक्षा की ज़रूरत पड़ी थी।

माप

यह ट्रैक करें कि रिलीज़ से पहले डिफेक्ट का कितना हिस्सा पकड़ा गया, और फेलियर से फ़िक्स तक कितना समय लगा। ये दोनों तभी हिलते हैं जब सचमुच कुछ बेहतर होता है, और ज़्यादा टेस्ट लिखकर इनमें से किसी के साथ खिलवाड़ नहीं किया जा सकता — यही इनकी असली खूबी है। टेस्ट की संख्या और कवरेज प्रतिशत, दोनों माँगने भर से बढ़ जाते हैं और लगभग कुछ नहीं बताते।

फिर भी टीमें इसके पीछे क्यों भागती रहती हैं

लक्ष्य गलत है, यह जान लेने भर से लोग उस पर निशाना लगाना बंद नहीं करते, और इसकी वजह समझने लायक है, क्योंकि वह भोलेपन की नहीं, ढाँचे की देन है।

बग दिखते हैं, रोकथाम नहीं दिखती। जो डिफेक्ट ग्राहक तक पहुँच गया, उसका एक टिकट होता है, एक नाम होता है और एक ज़िम्मेदार होता है। जो बारह रिलीज़ से पहले पकड़ लिए गए, उनका कुछ नहीं होता, क्योंकि कुछ हुआ ही नहीं। लिहाज़ा किसी तिमाही का दिखने वाला रिकॉर्ड नाकामियों की एक सूची होता है, और नाकामियों की सूची पर स्वाभाविक प्रतिक्रिया यही होती है कि उन्हें कम करने की माँग की जाए।

इसका जवाब यह है कि रोकथाम को भी दिखने लायक बनाया जाए। कितने डिफेक्ट बच निकले, यह बताने के साथ-साथ यह भी बताएँ कि कितने रिलीज़ से पहले पकड़ लिए गए। पहला आँकड़ा आम तौर पर कहीं बड़ा होता है, और उसे देखते ही बातचीत "हमारे यहाँ बग क्यों आते रहते हैं" से बदलकर "यह अनुपात हिल रहा है या नहीं" हो जाती है — और काम का जवाब इसी सवाल का मिलता है।

व्यवहार में यह कैसा दिखता है

हर बग के हिस्से एक जाँच आती है। जाँचें रिलीज़ से पहले नहीं, हर बदलाव पर चलती हैं। फेलियर ऐसी शक्ल में आते हैं कि ठीक करने वाला पूरी कहानी दोबारा गढ़े बिना उन पर काम शुरू कर सके।

जिन्हें लोकल इंस्टॉल नहीं चाहिए, उनके लिए डैशबोर्ड यही सब कवर करता है, और कमांड्स का पूरा दायरा मौजूद है CLI रिपॉज़िटरी में।

मैकेनिज़्म से ज़्यादा मायने ट्रिगर रखता है। इसे अपने डिप्लॉयमेंट इवेंट से जोड़ देने का मतलब है कि हर बदलाव की जाँच अपने आप होती है, किसी को अलग से तय नहीं करना पड़ता; GitHub App यह काम डैशबोर्ड से करता है, और GitHub Actions का एक स्टेप यही काम आपके वर्कफ़्लो के भीतर से कर देता है।

TestSprite इन तीन लक्ष्यों में कैसे साथ देता है

"कोई दोहराव नहीं" वह लक्ष्य है जिसमें यह सबसे सीधे काम आता है। जिस केस ने बग को दोबारा पैदा किया था, वह प्रोजेक्ट में बना रहता है और हर बदलाव पर चलता है, इसलिए फ़िक्स अपने पीछे एक जाँच छोड़ जाता है — किसी को याद रखकर जाँच लिखनी नहीं पड़ती।

"यूज़र्स से पहले पकड़ में आना" लय का मामला है। कवरेज आपके प्रोडक्ट से तैयार होता है और पुल रिक्वेस्ट पर चलता है, जिससे पकड़ प्रोडक्शन से खिसककर उसी बदलाव तक लौट आती है जिसने वजह बनाई।

"ठीक करना सस्ता" फेलियर रिपोर्ट पर टिका है। हर रन इस शक्ल में लौटता है कि क्या करने की कोशिश की गई, एप्लिकेशन ने क्या किया, और दोनों कहाँ अलग हुए — इसलिए जो भी इसे ठीक करे, और अब बढ़ते तौर पर यह कोडिंग एजेंट होता है, वह कहानी दोबारा जोड़ने के बजाय सबूत से शुरू करता है।