ऑटोमेटेड UI टेस्टिंग के लिए एक बेहतर फ़िल्टर
flows को इस आधार पर क्रम दें कि कोई खराबी कितने समय तक बिना पकड़ में आए पड़ी रह सकती है, न कि इस आधार पर कि वे कितने ज़रूरी हैं। एक export, एक invite, एक settings page, एक scheduled digest। इनमें से हर एक किसी न किसी के लिए मायने रखता है और किसी पर भी भीड़ की नज़र नहीं होती, इसलिए regression वहाँ महीने भर पड़ा रहता है।
दूसरा फ़िल्टर: flow कितनी बार बदलता है। जो screen हर sprint में redesign होती है, उसका maintenance उससे मिलने वाले फ़ायदे से ज़्यादा महंगा पड़ेगा। उसे तब कवर करें जब वह स्थिर हो जाए।
तीन लागतें
Selectors
ऐसा redesign जो functionality में कुछ नहीं बदलता, suite को लाल कर देता है।
असल में maintenance का ज़्यादातर समय यहीं जाता है।
इंतज़ार
तय delays धीमे होते हैं और फिर भी flaky रहते हैं। सही waits के लिए यह जानना ज़रूरी है कि इंतज़ार किस चीज़ का करना है।
ज़्यादातर flakiness की जड़ यहीं होती है।
हाथ से लिखा coverage
आप वही कवर करते हैं जो किसी ने लिखा है, यानी दिलचस्प flows, न कि वे जो टूटते हैं।
पहली दो को अनुशासन से संभाला जा सकता है। तीसरी संरचनात्मक है: हाथ से लिखा coverage लिखने वाले के समय से बंधा होता है, और वह समय बढ़ता नहीं।
तीन आदतें जो सबसे ज़्यादा बचाती हैं
स्थिर attributes पर टिकें। CSS path के बजाय एक अलग test attribute। इतने भर से redesign की ज़्यादातर टूट-फूट खत्म हो जाती है।
state का इंतज़ार करें, समय का कभी नहीं। element या response का इंतज़ार करें। तय delay धीमा भी है और भरोसेमंद भी नहीं।
वही assert करें जिसकी पुष्टि reload करने पर हो। success toast इस बात का सबूत नहीं है कि कुछ टिका भी।
suites क्यों हटा दी जाती हैं
इसलिए नहीं कि उनसे कुछ मिलता नहीं। बल्कि इसलिए कि असली failures और maintenance failures का अनुपात इतना बिगड़ जाता है कि लोग नतीजे पढ़ना ही बंद कर देते हैं। जिस दिन लाल build का मतलब "शायद कोई bug" के बजाय "शायद कोई selector" होने लगे, उस दिन suite ने काम करना बंद कर दिया, भले ही वह अब भी चलती हो।
असली काम उसी अनुपात को बचाना है, और यह इस बात पर ज़्यादा निर्भर करता है कि steps किस तरह लिखे गए हैं, न कि इस पर कि आपके पास कितने tests हैं।
ऐसा coverage जो लिखने वाले के समय पर निर्भर न हो
जो steps इरादों के रूप में लिखे जाते हैं, वे ऊपरी बदलावों से बच जाते हैं; और जो coverage किसी की याददाश्त के बजाय product से तैयार होता है, उसमें वे flows भी आ जाते हैं जिन्हें कोई लिखता ही नहीं। लागत का यही हिस्सा है जिसे अनुशासन ठीक नहीं कर सकता।
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
जिन्हें local install नहीं चाहिए, उनके लिए dashboard भी यही काम कर देता है, और पूरा command surface यहाँ मौजूद है — CLI repository।
suite का वह आकार जो काम का बना रहता है
एक आकार के बाद browser suite जितना देती है उससे ज़्यादा खर्च कराने लगती है, और वह आकार ज़्यादातर टीमों की उम्मीद से छोटा होता है।
अड़चन runtime नहीं, ध्यान है। तीस flows वाली suite ऐसी failures देती है जिनकी कोई जाँच करता है। तीन सौ flows वाली suite रोज़ एक लिस्ट देती है, और लिस्टों को पढ़ा नहीं जाता, उनका triage किया जाता है। जैसे ही triage शुरू होता है, हर अतिरिक्त test coverage नहीं, शोर जोड़ने लगता है, चाहे वह कितना ही अच्छा क्यों न लिखा गया हो।
इसलिए नया test जोड़ते समय काम का सवाल यह नहीं है कि flow मायने रखता है या नहीं। सवाल यह है कि शुक्रवार दोपहर इस test के fail होने पर क्या आप उसकी जाँच करेंगे। अगर ईमानदार जवाब यह है कि आप उसे दोबारा चला कर आगे बढ़ जाएँगे, तो वह test पहले से ही शोर है और उसे लिखना suite को और खराब करता है।
हर बदलाव पर इसे चलाएँ
trigger, mechanism से ज़्यादा मायने रखता है। इसे अपने deployment event से जोड़ने का मतलब है कि हर बदलाव की जाँच हो जाती है, बिना किसी के यह तय किए; GitHub App यह काम dashboard से करता है, और एक GitHub Actions step इसे आपके workflow के भीतर से करता है।
TestSprite गणित कहाँ बदल देता है
तीसरी लागत, यानी लिखने वाले के समय से बंधा coverage, वही है जिसे अनुशासन ठीक नहीं कर सकता, और यही TestSprite हटा देता है। Cases आपके product से तैयार होते हैं और सादी भाषा में निखारे जाते हैं, इसलिए चुपचाप पड़े रहने वाले flows भी कवर हो जाते हैं, बिना इसके कि कोई उन्हें लिखने के लिए दोपहर निकाले।
पहली दो लागतें साइड इफ़ेक्ट के तौर पर बेहतर हो जाती हैं। Steps को DOM के रास्तों के बजाय इरादों के रूप में सहेजा जाता है, इसलिए कोई redesign जो button को खिसका दे, suite को लाल नहीं करता; और इंतज़ार हर test में ट्यून करने के बजाय अपने आप संभाला जाता है। maintenance का ज़्यादातर समय इन्हीं दोनों में जाता है।
इससे वही आँकड़ा बचता है जो तय करता है कि suite टिकेगी या नहीं: लाल builds में असली bugs का हिस्सा। इसे ऊँचा रखिए और लोग नतीजे पढ़ते रहेंगे, और यही फ़र्क है असली coverage और रात में चलने वाले एक job के बीच।
हमारे पास कितने UI tests होने चाहिए?
आपकी सोच से कम, और चुने हुए इस आधार पर कि कोई खराबी कितनी चुपचाप बिना पकड़ में आए रह जाएगी। जिस छोटी suite पर लोग भरोसा करते हैं, वह उस बड़ी suite से बेहतर है जिसे लोग अनदेखा करते हैं।
स्वीकार करने लायक pass rate कितनी होनी चाहिए?
बहुत ऊँची दर से नीचे कुछ भी हो तो लोग नतीजे पढ़ना बंद कर देते हैं। flakiness के आखिरी कुछ प्रतिशत के पीछे लगना नए tests जोड़ने से ज़्यादा फ़ायदेमंद है।
क्या UI tests हर commit पर चलने चाहिए?
आम तौर पर सही जवाब है, हर pull request पर। हर commit पर चलाना अक्सर इतना धीमा होता है कि काम का नहीं रहता और उसे बंद कर दिया जाता है।
visual regression का क्या?
यह अलग मामला है और इसमें tolerance की अपनी समस्या है। design systems के लिए काम का, application screens के लिए शोर भरा।
क्या अब भी manual testing की ज़रूरत है?
exploratory काम के लिए और ऐसी किसी भी चीज़ के लिए जहाँ यह परखना हो कि कुछ सही लग रहा है या नहीं, हाँ। वही जाँचें बार-बार दोहराने के लिए, नहीं।
वही कवर करें जो चुपचाप fail हो जाएगा।
ऑटोमेटेड UI टेस्टिंग का चुनाव महत्व के बजाय इस आधार पर होना चाहिए कि कोई खराबी कितने समय तक बिना पकड़ में आए रह जाएगी। स्थिर attributes पर टिकें, state का इंतज़ार करें, वही assert करें जिसकी पुष्टि reload करने पर हो, और असली failures तथा maintenance के शोर के अनुपात को बचाए रखें।