ऑटोमेटेड सॉफ़्टवेयर टेस्टिंग एजेंट: स्वायत्तता कहाँ रुकनी चाहिए

ऑटोमेटेड सॉफ़्टवेयर टेस्टिंग एजेंट को क्या सौंपें

• किसी बदलाव से टेस्ट केस बनाना। जिस क्षण कोड लिखा जाता है, संदर्भ उसके पास उसी समय होता है — और तभी ब्यौरे सबसे ताज़ा होते हैं।

• टेस्ट चलाना और दोबारा चलाना। यांत्रिक काम है, और इस लूप में इंसान के होने से सिर्फ़ देरी जुड़ती है।

• साफ़ दिखने वाले फ़ेल्योर का ट्रायज करना। एनवायरनमेंट डाउन, डिपेंडेंसी ग़ायब, टारगेट तक पहुँच नहीं। इनमें विवेक की ज़रूरत नहीं पड़ती।

• जिस बग से वह टकराया, उसका रिप्रोडक्शन केस लिखना। केस तभी लिखा जाता है जब बग सामने होता है, न कि तीन दिन बाद किसी टिकट में।

अपने पास क्या रखें

एक वाक्य में वह सीमा

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

वह गार्डरेल जो रखने लायक है

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

दूसरे महीने में क्या गड़बड़ होती है

इस तरह काम करने के शुरुआती हफ़्ते अच्छे बीतते हैं, और उसके बाद एक अनुमान लगाने लायक गिरावट आती है, जिसके लिए पहले से तैयार रहना ठीक रहता है।

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

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

सेटअप कैसे करें

अगर आप लोकल मशीन पर कुछ भी इंस्टॉल नहीं करना चाहते, तो यही सेटअप TestSprite डैशबोर्ड में भी मौजूद है। बाक़ी पूरा CLI सरफ़ेस यहाँ है: CLI रिपॉज़िटरी।

डैशबोर्ड से रिपॉज़िटरी कनेक्ट कीजिए और रन उसी डिप्लॉयमेंट से शुरू हो जाएँगे जो आप पहले से बनाते हैं; या फिर इसके बजाय अपने वर्कफ़्लो में एक स्टेप जोड़ लीजिए।

TestSprite के ज़िम्मे क्या है और आपके पास क्या रहता है

‘कैसे’ उसका है: बदलाव से टेस्ट केस बनाना, उन्हें डिप्लॉय किए गए एप्लिकेशन पर चलाना, दोबारा चलाना, और यांत्रिक फ़ेल्योर का ट्रायज करना। सेटअप आपके कोडिंग एजेंट में वेरिफ़िकेशन स्किल इंस्टॉल कर देता है, ताकि यह सब वहीं हो जहाँ काम हो रहा है।

‘क्या’ आपके पास रहता है। प्लान पढ़ना, उन असर्शन को सुधारना जो टूटे हुए प्रोडक्ट पर भी सही उतरते, और यह तय करना कि कौन-से फ़ेल्योर रिलीज़ रोकते हैं। सामान्य वॉल्यूम पर यह हफ़्ते का एक घंटा है, और यही वह जगह है जहाँ प्रोडक्ट की आपकी समझ टेस्ट सुइट में दाख़िल होती है।

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