UI Testing Tools: किसी एक को चुनने से पहले क्या जाँचें

UI testing tools जाँच एक: रीडिज़ाइन पर क्या होता है

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

किसी भी वेंडर से कहिए कि वह इसे बताए नहीं, बल्कि करके दिखाए।

जाँच दो: दो सौवाँ टेस्ट कौन लिखता है

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

जाँच तीन: जो ठीक करेगा, उसे फ़ेलियर कैसा दिखता है

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

जाँच चार: जो रन किसी असर्शन तक पहुँचा ही नहीं, क्या वह पास दिखाया जाता है

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

करने लायक प्रयोग

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

फ़ेलियर के बारे में ठीक-ठीक क्या पूछें

हर वेंडर आपको पास होता हुआ रन दिखाएगा। किसी भी डेमो के काम के पाँच मिनट वही होते हैं जब आप फ़ेल होता हुआ रन दिखाने को कहते हैं — और वहाँ तीन चीज़ें देखनी चाहिए।

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

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

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

इनमें से किसी के भी साथ आने वाली लागतें

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

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

TestSprite इन चार जाँचों पर कैसा उतरता है

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

चौथी बात को किसी भी ट्रायल में ख़ुद परखना चाहिए — इसमें भी। कोई सेव तोड़ दीजिए ताकि वह सहेजना बंद कर दे, और पुष्टि कीजिए कि चेक लाल होता है।

नतीजा यह मिलता है: ऐसी कवरेज जो उस टीम के साथ क़दम मिलाकर चलती है जो टेस्ट लिख पाने से ज़्यादा तेज़ी से शिप करती है, और ऐसा फ़ेलियर सिग्नल जिसे लोग पढ़ते रहते हैं क्योंकि वह ज़्यादातर असली होता है।