UI automation testing का अनुपात किन वजहों से गिरता है
Selectors
ऐसा redesign जो functionality में कुछ नहीं बदलता, पूरी suite को red कर देता है।
maintenance का ज़्यादातर समय असल में यहीं जाता है।
Waiting
तय delay धीमे भी होते हैं और फिर भी flaky रहते हैं। सही wait के लिए यह पता होना चाहिए कि इंतज़ार किस चीज़ का करना है।
ज़्यादातर flakiness की जड़ यहीं होती है।
हाथ से लिखा गया coverage
आप वही cover करते हैं जो किसी ने लिखा है, यानी दिलचस्प flows — न कि वे जो टूटते हैं।
Selectors और waiting ऐसे failures पैदा करते हैं जो bugs नहीं होते। इनमें से हर एक टीम की उस इच्छा को थोड़ा-थोड़ा ख़र्च कर देता है जिसके सहारे वह अगला red build देखने बैठती है।
जिस पल कोई suite मर जाती है
पीछे मुड़कर देखने पर वह पल आमतौर पर पहचाना जा सकता है: वह हफ़्ता जब किसी ने कहा "बस दोबारा चला दो" और वह सही निकला। उसके बाद किसी भी failure पर पहली प्रतिक्रिया rerun करना बन जाती है, और कोई असली regression तब तक rerun होता रहता है जब तक क़िस्मत से pass न हो जाए या उसे quarantine न कर दिया जाए।
suite पर भरोसा करना छोड़ने का फ़ैसला कोई नहीं करता। वह धीरे-धीरे घिसकर ख़त्म हो जाता है।
अनुपात को बचाए रखना
नए tests जोड़ने से पहले flaky tests ठीक करें। यह बात लोगों को पसंद नहीं आती, पर सही है। जिस suite को लोग नज़रअंदाज़ करते हैं, उसमें जोड़े गए नए test की कोई क़ीमत नहीं।
Quarantine खुलकर करें, चुपचाप नहीं। skip किया गया test दिखना चाहिए और उसका कोई owner होना चाहिए, वरना skip list वह जगह बन जाती है जहाँ tests मरने के लिए जाते हैं।
हर rerun को एक finding मानें। अगर किसी test को rerun की ज़रूरत पड़ी, तो या तो test में कुछ गड़बड़ है या environment में। आगे बढ़ जाने के बजाय उसे दर्ज करें।
ढाँचागत हिस्सा
अनुशासन selectors और waits को सँभाल लेता है। लेकिन तीसरी लागत को नहीं सँभालता: coverage की सीमा इस बात से तय होती है कि कोई इंसान कितना लिख सकता है, और product इससे तेज़ी से बढ़ता है — ख़ासकर तब जब ज़्यादातर code किसी coding agent से आ रहा हो।
जब steps को DOM के रास्तों के बजाय इरादों के रूप में लिखा जाता है, तो selector failures का एक बड़ा हिस्सा सीधे ख़त्म हो जाता है, और यही अनुपात पर असर डालने वाला सबसे बड़ा अकेला कारक है।
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
अगर आप स्थानीय रूप से कुछ भी install नहीं करना चाहते, तो यही setup TestSprite dashboard में भी उपलब्ध है। बाक़ी पूरा CLI surface यहाँ देखें: CLI repository।
बिगड़े हुए अनुपात को वापस सुधारना
अगर suite पहले ही उस हालत में पहुँच चुकी है जहाँ लोग जाँच करने के बजाय rerun करते हैं, तो आगे से अनुशासन बरतने भर से बात नहीं बनेगी, क्योंकि पहले से मौजूद शोर उसी आदत को पुख़्ता करता रहता है। उबरने के लिए जान-बूझकर एक reset करना पड़ता है।
पिछले पचास failures लें और हर एक को असली, selector, timing या environment में बाँटें। वह एक घंटा बता देगा कि तीनों लागतों में से असल में आपकी समस्या कौन-सी है, और यह आमतौर पर बिखरी हुई नहीं, एक जगह जमा होती है। tests को fail होते ही एक-एक करके ठीक करने के बजाय उस एक श्रेणी को पूरी suite में ठीक करें।
इसके बाद जो कुछ भी अब भी fail हो रहा है उसे owner और तारीख़ के साथ quarantine कर दें, और बची हुई suite को green रहने दें। एक छोटी green suite जिस पर लोग भरोसा करते हैं, उस बड़ी red suite से ज़्यादा क़ीमती है जिसे नज़रअंदाज़ करना वे सीख चुके हैं — और अनुपात सिर्फ़ इसी हालत से बेहतर हो सकता है।
इसे वहाँ चलाएँ जहाँ failures सबसे सस्ते पड़ें
हर pull request पर, ताकि कोई failure हफ़्ते भर के बदलावों के बजाय किसी एक बदलाव की ओर इशारा करे।
GitHub App एक webhook है जिसे आप TestSprite dashboard में सेट करते हैं। यह उसी deployment event को सुनता है जो आपकी pipeline पहले से पैदा करती है, इसलिए आपकी repository में कुछ नहीं बदलता।
GitHub Actions इस step को आपके अपने workflow के अंदर रखता है, जिसे terminal से configure किया जाता है।
TestSprite इस अनुपात को कैसे बचाता है
सीधे तौर पर — झूठे failures के सबसे बड़े स्रोत को हटाकर। Steps locators नहीं, इरादे होते हैं, इसलिए जो दिखावटी बदलाव ज़्यादातर selector टूटन पैदा करते हैं, वे red builds नहीं बनाते। Waiting अपने आप सँभाल लिया जाता है, यह हर test के लिए अलग से ट्यूनिंग का काम नहीं रह जाता, जिससे बाक़ी बचा ज़्यादातर हिस्सा भी हट जाता है।
Coverage आपके product से तैयार होता है और सामान्य भाषा में निखारा जाता है, इसलिए suite बढ़ाने का मतलब उसी अनुपात में maintenance बढ़ाना नहीं होता — और यही वह चीज़ है जो आमतौर पर coverage और भरोसे के बीच सौदा करने पर मजबूर करती है।
नतीजा एक ऐसी suite है जिसमें failure होना हैरानी की बात हो। यही वह हालत है जिसमें लोग rerun करने के बजाय जाँच करते हैं, और सिर्फ़ इसी हालत में coverage बढ़ता रह सकता है, बिना इसके कि पूरी व्यवस्था चुपचाप महज़ दिखावा बनकर रह जाए।
हमें कितने pass rate की उम्मीद रखनी चाहिए?
इतना ऊँचा कि red build आना हैरानी की बात हो। अगर failures रोज़मर्रा की बात हैं, तो suite product के बारे में नहीं, अपने बारे में रिपोर्ट कर रही है।
flaky tests कैसे ठीक करें?
पता करें कि मामला selector का है या wait का। Selectors को स्थिर anchors चाहिए, waits को state का इंतज़ार करना चाहिए। एक तीसरी श्रेणी सचमुच अस्थिर environment की है, जिसे test में कोई बदलाव ठीक नहीं कर सकता।
क्या पुराने tests हटा देना सही है?
हाँ। जिस test पर न कोई भरोसा करता है और न कोई उसे maintain करता है, वह बिना फ़ायदे की लागत है। उसे skip करने से बेहतर है उसे हटा देना।
क्या suite को merges रोकने चाहिए?
जब अनुपात ठीक हो जाए, तब हाँ। उससे पहले, भरोसे के लायक़ न रह गई suite पर merges रोकना लोगों को उसे bypass करना सिखा देता है।
इसे मापें कैसे?
यह ट्रैक करें कि कितने failures असली निकलते हैं। अगर यह आँकड़ा किसी को पता ही नहीं, तो यही अपने आप में finding है।
जो आँकड़ा मायने रखता है वह coverage नहीं है।
UI automation testing की ज़िंदगी और मौत इसी पर टिकी है कि कितने red builds असली bugs निकलते हैं। नए tests जोड़ने से पहले flaky tests ठीक करें, हर rerun को एक finding मानें, और भरोसे को घिसने वाले selector failures हटाने के लिए इरादों पर आधारित steps इस्तेमाल करें।