UI ऑटोमेशन टूल्स की तीन श्रेणियाँ
कोड फ़्रेमवर्क। आप टेस्ट किसी असली प्रोग्रामिंग भाषा में लिखते हैं। मानकर चलता है: ऐसे इंजीनियर जिनके पास लिखने और मेंटेन करने का समय हो।
रिकॉर्ड और लो-कोड। कोई व्यक्ति एडिटर में फ़्लो बनाता है। मानकर चलता है: कोई ऐसा व्यक्ति जिसका काम ही टेस्ट फ़्लो बनाना है।
एजेंट-आधारित। कवरेज जनरेट होती है और नैचुरल लैंग्वेज में उसे सँवारा जाता है। मानकर चलता है: आप उस कवरेज की समीक्षा करेंगे जो आपने खुद नहीं लिखी।
कौन-सी धारणा सबसे ज़्यादा गलत साबित होती है
दूसरी। लो-कोड प्लेटफ़ॉर्म एक टेस्टिंग फ़ंक्शन को केंद्र में रखकर बनाए जाते हैं, और बहुत-सी टीमों में अब ऐसा कोई फ़ंक्शन बचा ही नहीं है। प्लेटफ़ॉर्म ठीक है, लाइसेंस का पैसा भी चुकाया जा चुका है, पर फ़्लो कोई नहीं बना रहा — यानी कवरेज उसी महीने बढ़ना बंद हो जाती है जिस महीने आख़िरी टेस्टर ने कंपनी छोड़ी।
पहली धारणा धीरे-धीरे टूटती है। इंजीनियर टेस्ट लिख तो सकते हैं, लेकिन यह काम फ़ीचर शिप करने से होड़ करता है — इसलिए सुइट पहली तिमाही में बढ़ती है और फिर रुक जाती है।
फ़ीचर ग्रिड से बेहतर काम करने वाले सवाल
दो सौवाँ टेस्ट कौन लिखेगा? पहले दस तो इवैल्यूएशन के दौरान ही लिख लिए जाते हैं। सवाल छठे महीने का पूछिए।
जब UI दोबारा डिज़ाइन होता है, तब क्या होता है? यही वह बार-बार आने वाली लागत है, और इसका जवाब हर श्रेणी में एकदम अलग होता है।
जो इसे ठीक करेगा, उसे फ़ेल्योर कैसा दिखता है? आजकल यह ज़िम्मा तेज़ी से किसी कोडिंग एजेंट के पास जा रहा है, जो स्क्रीनशॉट का मतलब नहीं निकाल सकता।
क्या ऐसा रन, जो अपनी असर्शन तक पहुँचा ही नहीं, पास के रूप में रिपोर्ट होता है? इसे जानबूझकर जाँचना चाहिए, क्योंकि जवाब कभी-कभी हाँ होता है।
वह लागत जो तुलना में कहीं नहीं दिखती
यहाँ बताई गई हर श्रेणी के साथ एक लगातार चलने वाली लागत जुड़ी है, जिसे वेंडर आँकड़ों में नहीं बताते क्योंकि वह उन पर नहीं, आप पर निर्भर करती है: यह तय करने की लागत कि कवर क्या करना है।
कोड फ़्रेमवर्क में कोई टेस्ट लिखता है, यानी पहले किसी ने तय किया कि यह टेस्ट होना चाहिए। लो-कोड एडिटर में भी यही बात है। जनरेट की गई कवरेज में यह तय करना प्लान की समीक्षा में बदल जाता है — जो तेज़ तो है पर मुफ़्त नहीं, और अक्सर छोड़ दिया जाता है, जिससे वह हालत बनती है जिसमें कवरेज तो है पर उसे पढ़ा किसी ने नहीं।
आप जो भी चुनें, इसे बजट में साफ़ तौर पर शामिल करें। हफ़्ते में एक घंटा कोई यह देख ले कि क्या कवर है और क्या नहीं — यही फ़र्क है उस सुइट में जो आपके प्रोडक्ट को दिखाती है, और उस सुइट में जो यह दिखाती है कि अठारह महीने पहले जो कुछ ऑटोमेट करना आसान था वह क्या था।
मूल्यांकन कैसे करें
जानबूझकर कुछ तोड़िए। कोई असली रिग्रेशन डालिए — जैसे ऐसा सेव जो अब सहेजा ही नहीं जाता — और देखिए कि हर उम्मीदवार टूल क्या रिपोर्ट करता है। क्या वह फ़ेल होता है, क्या फ़ेल्योर यह बताता है कि फ़र्क कहाँ पड़ा, और क्या ठीक करने वाला उस आउटपुट से काम शुरू कर सकता है। यह एक अभ्यास आपको महीने भर की फ़ीचर तुलना से ज़्यादा बताएगा।
टर्मिनल
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप कुछ भी इंस्टॉल नहीं करना चाहते, तो डैशबोर्ड से भी यही काम हो जाता है। कमांड लाइन जो कुछ और कर सकती है, उसकी पूरी जानकारी के लिए देखिए CLI रिपॉज़िटरी।
दो रास्ते हैं, और चुनाव असल में इस बात का है कि पाइपलाइन किसके ज़िम्मे है। डैशबोर्ड से GitHub App जोड़ने पर आपकी रिपॉज़िटरी में कोई बदलाव करने की ज़रूरत ही नहीं पड़ती, क्योंकि यह उसी डिप्लॉयमेंट पर प्रतिक्रिया देता है जो आपका बिल्ड पहले से भेजता है। वहीं GitHub Actions का स्टेप जोड़ने से यह जाँच रिपॉज़िटरी के भीतर आ जाती है, जहाँ बाकी बिल्ड की तरह इसकी भी समीक्षा होती है।
TestSprite किस धारणा पर चलता है
यही कि आप उस कवरेज की समीक्षा करेंगे जो आपने खुद नहीं लिखी। सौदा यही है: किसी लेखक की ज़रूरत नहीं पड़ती, और बदले में कोई प्लान पढ़ता है और उसे दुरुस्त करता है।
ठोस तौर पर: केस आपके प्रोडक्ट से जनरेट होते हैं, स्टेप्स को इरादों के रूप में लिखा जाता है ताकि वे रीडिज़ाइन के बाद भी टिके रहें, और फ़ेल्योर इस रूप में लौटता है कि क्या करने की कोशिश की गई, ऐप ने क्या किया और दोनों कहाँ अलग हुए — जिस पर कोई कोडिंग एजेंट उतनी ही आसानी से काम कर सकता है जितनी आसानी से कोई इंसान।
जिस टीम में अलग से कोई टेस्टिंग फ़ंक्शन नहीं है, उसके लिए यह धारणा बाकी दोनों के मुकाबले पूरी करना आसान है, क्योंकि प्लान की समीक्षा में हफ़्ते का एक घंटा लगता है, जबकि पूरी सुइट लिखने के लिए एक पूरा रोल चाहिए। अगर वह रोल आपके पास है, तो कोड फ़्रेमवर्क आपके लिए बेहतर हो सकता है — और चुनने का ईमानदार तरीका यही है कि पूछा जाए कि साल भर में आपकी टीम असल में कौन-सी धारणा पूरी कर पाएगी।
क्या हम श्रेणियों को मिला सकते हैं?
हाँ, और ज़्यादातर टीमें आख़िर में यही करती हैं। सोच-समझकर तय किए गए फ़्लो के लिए कोड फ़्रेमवर्क और दायरा बढ़ाने के लिए जनरेट की गई कवरेज — यह बँटवारा आम है।
क्या ओपन सोर्स काफ़ी है?
अक्सर हाँ, और लागत कभी लाइसेंस थी ही नहीं। लागत टेस्ट लिखने और मेंटेन करने की है, जिसे ओपन सोर्स बदलता नहीं।
रिकॉर्ड और रीप्ले का क्या?
बनाने में तेज़, मेंटेन करने में महँगा, क्योंकि रिकॉर्डिंग इरादे को नहीं, एक रास्ते को पकड़ती है। एक-बार के रीप्रोडक्शन के लिए काम का है।
मूल्यांकन कितने समय तक चलना चाहिए?
इतने समय तक कि उसमें कोई रीडिज़ाइन या कोई असली रिग्रेशन आ जाए। जिस ट्रायल में इनमें से कुछ भी न दिखे, उसने वह चीज़ परखी ही नहीं जो मायने रखती है।
सबसे आम गलती क्या है?
उस टीम को ध्यान में रखकर चुनना जो आप चाहते हैं कि आपके पास होती। चुनाव उस टीम के लिए कीजिए जो छह महीने बाद इसे मेंटेन कर रही होगी।
हर श्रेणी आपकी टीम के बारे में कुछ न कुछ मानकर चलती है।
UI ऑटोमेशन टूल्स या तो कोड फ़्रेमवर्क होते हैं, या लो-कोड एडिटर, या एजेंट-आधारित। हर एक अलग तरह की टीम मानकर चलता है, और सबसे ज़्यादा जो धारणा गलत साबित होती है वह यह है कि आपके पास कोई ऐसा व्यक्ति है जिसका काम ही फ़्लो लिखना है। चुनाव उस टीम के लिए कीजिए जो असल में आपके पास होगी।