"AI टेस्टिंग" एक अनुपयोगी श्रेणी क्यों है
श्रेणियाँ आमतौर पर किसी समस्या का नाम होती हैं। यह श्रेणी एक तकनीक का नाम है, इसीलिए इसके भीतर तीन ऐसी समस्याएँ आ जाती हैं जिनके लक्षण अलग हैं, खरीदार अलग हैं और नाकाम होने के तरीके भी अलग हैं। कुछ भी तुलना करने से पहले साफ़ शब्दों में कह लेना चाहिए कि आपके पास इनमें से कौन-सी है।
पहली किस्म: वह AI जो आपके लिए टेस्ट लिखता है
यह जो समस्या हल करता है: आपके पास ऐसा कोड है जिसके कोई टेस्ट नहीं हैं, और उन्हें हाथ से लिखना धीमा और उबाऊ काम है।
यह दिखता कैसा है: आप किसी टूल को एक फंक्शन, एक फ़ाइल या एक स्पेसिफिकेशन पर लगाते हैं, और वह ऐसा टेस्ट कोड बना देता है जिसे आप commit कर सकते हैं।
यह कहाँ रुक जाता है: बनाए गए टेस्ट उसी कोड की मान्यताएँ अपना लेते हैं जिससे वे बने हैं। अगर implementation यह समझने में ही चूक गया है कि कोई endpoint क्या लौटाता है, तो बना हुआ टेस्ट उसी गलतफ़हमी को assert करेगा और पास हो जाएगा। यही इस पूरी श्रेणी की चुपचाप मौजूद सीमा है। कवरेज बढ़ता है, भरोसा नहीं बढ़ना चाहिए — कम से कम उतना नहीं जितना वह आंकड़ा दिखाता है।
आपको यह चाहिए अगर: आपकी कमी मात्रा की है। बिना टेस्ट वाला बहुत सारा कोड पड़ा है और किसी के पास समय नहीं है।
दूसरी किस्म: वह AI जो टेस्ट चलाता और उनका रखरखाव करता है
यह जो समस्या हल करता है: आपके पास सूट पहले से है और उसे ज़िंदा रखना महँगा पड़ रहा है। redesign होते ही selectors टूट जाते हैं, टेस्ट flaky रहते हैं, और हर sprint का एक अच्छा-खासा हिस्सा उन्हें ठीक करने में चला जाता है।
यह दिखता कैसा है: जब इंटरफ़ेस बदलता है तो runner खुद को उसके हिसाब से ढाल लेता है। जिस बटन का लेबल या जगह बदल गई है, वह फिर भी मिल जाता है, क्योंकि हर स्टेप को DOM के एक तय रास्ते की तरह नहीं, बल्कि एक इरादे की तरह समझा जाता है।
यह कहाँ रुक जाता है: यह ढल जाना दोधारी तलवार है। जो सूट किसी असली regression के इर्द-गिर्द खुद को ठीक कर लेता है, वह फेल हो जाने वाले सूट से भी बुरा है, क्योंकि वह ठीक उसी बात को छिपा देता है जो आप जानना चाहते थे। काम का संस्करण वही है जो इंटरफ़ेस बदलने और व्यवहार बदलने में फ़र्क़ कर सके, और सिर्फ़ पहले को माफ़ करे।
आपको यह चाहिए अगर: आपकी कमी रखरखाव की है। टेस्ट मौजूद हैं, और उन्हें हरा बनाए रखना ही वह कीमत है जो आप चुका रहे हैं।
तीसरी किस्म: AI के लिखे कोड की जाँच
यह जो समस्या हल करता है: आपकी टीम कोडिंग एजेंट का बनाया कोड इतनी तेज़ी से ship कर रही है कि कोई उसे पढ़ ही नहीं पाता, और जो review पहले गलतियाँ पकड़ लेता था वह चुपचाप एक औपचारिकता बनकर रह गया है।
यह दिखता कैसा है: deploy किया हुआ ऐप्लिकेशन ठीक वैसे ही चलाकर देखा जाता है जैसे कोई इंसान उसे इस्तेमाल करता, और नतीजा ऐसे सबूत के रूप में वापस आता है जिस पर एजेंट सीधे काम कर सके — यानी सुधार उसी लूप में हो जाता है जिसमें बदलाव हुआ था।
यह किसके साथ मिलकर चलता है: लॉजिक के लिए तेज़ लोकल यूनिट टेस्ट, और लोड के लिए कोई अलग औज़ार। यह परत उस सवाल का जवाब देती है जो वे दोनों नहीं दे सकते: क्या यह फ़ीचर चलते हुए प्रोडक्ट में सचमुच काम करता है।
आपको यह चाहिए अगर: आपकी कमी भरोसे की है। कोड की मात्रा बढ़ गई, review की क्षमता नहीं बढ़ी, और कोई भरोसे से नहीं कह सकता कि पिछले बीस merges ने कुछ तोड़ा या नहीं।
आपको असल में किस तरह की AI टेस्टिंग चाहिए
एक छोटी जाँच, उसी क्रम में जिस क्रम में सवाल पूछने चाहिए।
इसका जवाब हाँ है
"हमारे पास टेस्ट लगभग हैं ही नहीं।"
"हमारे पास टेस्ट बहुत हैं, और उनमें से आधे ऐसी वजहों से लाल हैं जिनका हमारे प्रोडक्ट से कोई लेना-देना नहीं।"
"टेस्ट हरे हैं, फिर भी रिलीज़ टूटती हैं, और हमारा ज़्यादातर कोड अब एजेंट से आता है।"
तो आपकी समस्या है
मात्रा। पहली किस्म।
रखरखाव। दूसरी किस्म।
भरोसा। तीसरी किस्म।
गलत टूल खरीदने का नतीजा ऐसा दिखता है
कवरेज बढ़ता है, incidents कम नहीं होते।
flakiness कम हो जाती है, छूटने वाले defects उतने ही रहते हैं।
ऐसा डैशबोर्ड जिसे कोई नहीं खोलता, क्योंकि वह उस सूट की रिपोर्ट देता है जिसे किसी ने लिखा ही नहीं।
तीसरी पंक्ति पर ठहरकर सोचने लायक है। बढ़ता कवरेज और घटती flakiness — दोनों नापना आसान है, और दोनों में से कोई वह चीज़ नहीं है जो आप असल में चाहते थे। आप चाहते थे production में कम चौंकाने वाली घटनाएँ।
वह एक सवाल जो गंभीर टूल को डेमो से अलग करता है
आप किसी भी किस्म का टूल देख रहे हों, यह पूछिए कि फेल होने पर क्या होता है।
डेमो आपको एक लाल पंक्ति दिखा देता है। जिस टूल के साथ आप सचमुच काम कर सकते हैं, वह बताता है कि क्या करने की कोशिश की गई थी, ऐप्लिकेशन ने उसकी जगह क्या किया, और दोनों कहाँ अलग हो गए — और यह सब ऐसे रूप में, जिसे ठीक करने वाला पूरी कहानी दोबारा जोड़े बिना इस्तेमाल कर सके। अगर किसी failure का जवाब बस एक स्क्रीनशॉट और एक stack trace है, तो मतलब निकालने का काम अब भी किसी इंसान को करना है — और वही इंसान वह bottleneck है जिसे आप हटाना चाहते थे।
जब ठीक करने वाला इंसान नहीं बल्कि एजेंट हो, तो यह बात दोगुनी अहम हो जाती है, क्योंकि एजेंट स्क्रीनशॉट को घूरकर इरादा नहीं भाँप सकता।
दूसरा सवाल: क्या यह आपके बिना चलता है
यहाँ बताई गई हर श्रेणी बेमानी हो जाती है अगर टेस्ट तभी चलें जब किसी को याद आए। जो सूट तय समय पर या हर pull request पर अपने आप चलता है, वही असल में काम कर रहा है। जो सूट किसी इंसान के शुरू करने का इंतज़ार करता है, वह काम नहीं, बस उस काम का दस्तावेज़ है जो कोई करना चाहता था।
इसलिए सेटअप का सवाल यह नहीं है कि किस टूल का assertion syntax बेहतर है। सवाल यह है कि पहली ही बैठक के अंत में कौन-सा टूल आपकी pipeline में जुड़ा हुआ एक check छोड़ जाता है, न कि स्क्रीन पर एक रिपोर्ट।
हम कहाँ खड़े हैं, साफ़-साफ़
TestSprite तीसरी समस्या के लिए बना है। यह आपके चलते हुए ऐप्लिकेशन को खोलता है, उसे किसी असली यूज़र की तरह इस्तेमाल करता है, और जो टूटा उसे एक ऐसे बंडल के रूप में लौटाता है जिस पर आपका कोडिंग एजेंट काम कर सके। यह टेस्ट केस भी बनाता है, पर वह जाँच के काम आने के लिए है, अपने आप में मकसद नहीं।
अगर आपकी कमी भरोसे की है, तो यह ठीक उसी समस्या के लिए बना है; और इसे परखने का सबसे तेज़ तरीका यह है कि इसे उस बदलाव पर लगाइए जो आपके एजेंट ने इसी हफ़्ते ship किया, और देखिए क्या लौटकर आता है।
तीनों में से TestSprite किसके लिए बना है
तीसरी के लिए। TestSprite उन टीमों के लिए है जिनके टेस्ट हरे हैं, फिर भी रिलीज़ टूटती हैं, और जिनका कोड लगातार बढ़ती मात्रा में एजेंट से इतनी तेज़ी से आता है कि कोई उसका review नहीं कर पाता।
ठोस शब्दों में: यह आपके चलते हुए ऐप्लिकेशन को खोलता है, उसे वैसे ही चलाकर देखता है जैसे कोई इंसान देखता, और जो टूटा उसे एक अकेले, आपस में मेल खाते बंडल के रूप में लौटाता है जिस पर आपका कोडिंग एजेंट काम कर सके। टेस्ट केस आपके अपने प्रोडक्ट से बनते हैं और सामान्य भाषा में सुधारे जाते हैं, इसलिए कवरेज इस बात पर नहीं टिकता कि किसी को कभी एक पूरी दोपहर मिल जाए। स्टेप selectors नहीं, इरादे होते हैं, इसलिए ऐसा redesign जिससे काम-काज में कुछ नहीं बदलता, पूरे सूट को लाल नहीं कर देता।
यह टेस्ट केस भी बनाता है, जो पहली कमी को छूता है, और इसके स्टेप इंटरफ़ेस बदलने के बाद भी टिके रहते हैं, जो दूसरी कमी को छूता है। लेकिन ये दोनों नतीजे तक पहुँचने के साधन हैं, अपने आप में मकसद नहीं। अगर आपकी असली शिकायत यह है कि टेस्ट लिखना उबाऊ काम है, या यह कि आपका मौजूदा सूट flaky है, तो इन्हीं में से किसी एक के इर्द-गिर्द बना प्रोडक्ट आपके ज़्यादा काम आएगा — और यह बात trial के दौरान नहीं, उससे पहले कह देना ही ठीक है।
क्या एक ही टूल तीनों काम संभाल सकता है?
कुछ हद तक, और ओवरलैप सचमुच होता है। पर हर प्रोडक्ट का केंद्र दिख ही जाता है। टेस्ट कोड बनाने के इर्द-गिर्द बना प्रोडक्ट कवरेज के लिए अनुकूलित होता है; जाँच के इर्द-गिर्द बना प्रोडक्ट नतीजे की गुणवत्ता के लिए। पूछिए कि प्रोडक्ट खुद को किस पैमाने पर नापता है।
क्या AI टेस्टिंग मैनुअल QA की जगह ले लेती है?
यह दोहराव वाले regression पास की जगह लेती है। exploratory टेस्टिंग, यह समझ कि क्या मायने रखता है, और किसी उलझे हुए flow के लिए "सही" का मतलब तय करना — ये अब भी इंसान का काम हैं, और असली कीमत हमेशा से दूसरे वाले में रही है।
मुझे कैसे पता चले कि पास हुए टेस्ट का कोई मतलब है?
देखिए कि उसने assert क्या किया। ऐसा run जो किसी assertion तक पहुँचे बिना पूरा हो गया, वह पास नहीं है; और जो टूल उसे पास बताता है, वह किसी टूल के न होने से भी बुरा है। टूल परखते समय जानबूझकर कुछ तोड़कर इसकी जाँच कर लेनी चाहिए।
क्या खुद को ठीक करने वाला सूट भरोसेमंद होता है?
सिर्फ़ तब, जब वह इंटरफ़ेस के बदलावों के आसपास खुद को ठीक करे और व्यवहार बदलने पर फेल हो जाए। पूछिए कि प्रोडक्ट इन दोनों में फ़र्क़ कैसे करता है, और "AI खुद समझ लेता है" को जवाब मत मानिए।
छोटी टीम कहाँ से शुरू करे?
उस flow से, जिसके टूटने पर आपको सबसे ज़्यादा शर्मिंदगी होगी — और उसे हर pull request पर चलने के लिए जोड़ दीजिए। एक टेस्ट केस जो हमेशा चलता है, उन पचास से ज़्यादा कीमती है जो सिर्फ़ रिलीज़ से पहले चलते हैं।
टूल की तुलना करने से पहले अपनी समस्या का नाम तय कीजिए।
मात्रा, रखरखाव और भरोसा — ये तीन अलग-अलग कमियाँ हैं। पहले तय कीजिए कि आपके पास कौन-सी है, फिर हर संभावित टूल से दो सवाल पूछिए: failure दिखता कैसा है, और क्या पहली बैठक के अंत में आपकी pipeline में कोई check चलने लगता है।