ब्राउज़र ऑटोमेशन की तीन पीढ़ियाँ: इनपुट सिमुलेशन, प्रोटोकॉल नियंत्रण और मॉडल निर्णय

ब्राउज़र ऑटोमेशन को बीस साल से अधिक हो चुके हैं, और इस दौरान इसकी मुख्य दिशा तीन बार बदली है। दिलचस्प बात यह है कि हर पीढ़ी अलग तरह की समस्या हल करती है, और एक समस्या हल होते ही bottleneck किसी नई जगह पहुँच जाता है।

पहली पीढ़ी: ऑपरेटिंग सिस्टम स्तर पर ऐसा दिखाना कि कोई व्यक्ति माउस चला रहा है

सबसे शुरुआती ऑटोमेशन वास्तव में ब्राउज़र के अंदर नहीं, बल्कि ऑपरेटिंग सिस्टम स्तर पर चलता था। स्क्रिप्ट माउस को चलाती और कुंजियाँ दबाती थी, जबकि ब्राउज़र केवल इन इनपुट को निष्क्रिय रूप से स्वीकार करता था।

इसका फायदा इसकी व्यापक उपयोगिता थी: स्क्रीन पर जो कुछ दिखता था, उससे यह इंटरैक्ट कर सकता था—वेब पेज, client application या पुराना desktop software—और ब्राउज़र को कोई विशेष interface देने की ज़रूरत नहीं थी। इसकी कीमत भी साफ थी। स्क्रिप्ट screen coordinates पर निर्भर थी, इसलिए resolution, system scaling या window position बदलते ही वही action गलत जगह क्लिक कर सकता था। उसे यह भी पता नहीं होता था कि पेज वास्तव में लोड हुआ है या नहीं, इसलिए fixed wait पर निर्भर रहना पड़ता था। Parallel execution और कठिन था: एक machine में एक ही mouse और keyboard होता है, इसलिए दस environments के लिए दस machines चाहिए थीं।

इस पीढ़ी की बची हुई समस्या सीधी थी: यह पेज को देख नहीं सकती थी।

दूसरी पीढ़ी: स्क्रीन को छोड़कर सीधे ब्राउज़र से बात करना

WebDriver के आने से ऑटोमेशन pixel level से element level पर पहुँचा: अब स्क्रीन के 800वें pixel की स्थिति नहीं, बल्कि पेज के भीतर कोई विशेष element खोजा जाता था। वही code अलग-अलग browsers चला सकता था और अलग-अलग languages में लिखा जा सकता था। यही कारणों में से एक था कि यह बाद में testing के क्षेत्र में standard बन गया।

इसके बाद browser debugging protocols पर आधारित समाधानों ने इस रास्ते को और विकसित किया। Puppeteer और Playwright सीधे browser engine से संवाद करते हैं और पेज की अंदरूनी स्थिति प्राप्त कर सकते हैं: element के तैयार होने का स्वतः इंतज़ार, requests को intercept और rewrite करना, पहले से खुले browser instance से जुड़ना, headless चलना और कई contexts को parallel में खोलना। आज सामान्य मानी जाने वाली बहुत-सी क्षमताएँ इसी चरण में पूरी हुईं।

इसने control और stability की समस्या हल की, लेकिन दो दूसरी समस्याएँ छोड़ दीं। पहली, scripts अब भी लोग पहले से तय करके लिखते थे। Page structure बदलने या selector टूटने पर code में लौटकर बदलाव करना पड़ता था, और project के बढ़ने के साथ maintenance cost भी बढ़ती थी। दूसरी समस्या अधिक मूलभूत थी: यह इस बात को नियंत्रित करता है कि काम कैसे किया जाए, यह नहीं कि काम करने वाला बाहर से कैसा दिखाई दे। Protocol से सीधा connection control को अधिक सटीक बनाता है, लेकिन communication method बदलने से automation के निशान अपने-आप नहीं मिटते। बहुत स्थिर script भी दूसरों को script ही लग सकती है।

तीसरी पीढ़ी: हर कदम इंसान नहीं लिखता, और समस्या फिर दूसरी जगह चली जाती है

तीसरी पीढ़ी में बदलाव control method में नहीं, decision method में है। पहली दो पीढ़ियों में हर कदम इंसान को स्पष्ट रूप से लिखना पड़ता था: कौन-सा button क्लिक करना है, कौन-सा field भरना है और किस क्रम में आगे बढ़ना है। Model-driven पीढ़ी में लक्ष्य दिया जाता है, रास्ता model स्वयं तय करता है, और page redesign होने पर वह नया entry point खोज सकता है।

इससे selector कैसे लिखना है या कितना इंतज़ार करना है जैसी पुरानी बारीक समस्याएँ धीरे-धीरे कम महत्वपूर्ण हो जाती हैं। लेकिन नई समस्याएँ तुरंत सामने आती हैं।

मुख्य बात यह है कि model स्वयं web page को access नहीं करता। Page खोलना, resources लोड करना और login state बनाए रखना अभी भी browser का काम है। इसलिए जब कोई task अस्थिर होने लगता है, कारण अक्सर model का गलत निर्णय नहीं बल्कि उसके नीचे का execution environment होता है: कई tasks एक browser साझा करते हैं और cookies तथा cache एक-दूसरे को प्रभावित करते हैं; fingerprint characteristics बहुत समान होते हैं, इसलिए platform को सभी tasks एक ही machine से आते दिखते हैं; accounts tasks के बीच इस्तेमाल होते हैं और एक anomaly कई tasks को प्रभावित कर सकती है; environments अस्थायी रूप से बनाने और उपयोग के बाद वापस लेने पड़ते हैं, लेकिन unified scheduling नहीं होता। Model यह हल करता है कि काम कैसे किया जाए, और काम कहाँ किया जाए नया bottleneck बन जाता है।

Architecture में जुड़ने वाली अतिरिक्त layer

तीनों पीढ़ियों को साथ देखें तो अंतर यह नहीं है कि कौन अधिक advanced है। हर पीढ़ी को वह चीज़ संभालनी पड़ती है जिसे पिछली पीढ़ी नहीं संभाल सकी। पहली दो पीढ़ियों में environment बड़ी समस्या नहीं था, क्योंकि automation अपनी machine के browser पर चलता था। Agent stage में tasks बड़े पैमाने पर, parallel और unattended होते हैं, इसलिए environment को स्पष्ट रूप से manage करना पड़ता है: हर task अलग environment में चलता है; fingerprints और sessions आपस में नहीं मिलते; login state tasks के बीच बनी रहती है ताकि हर बार फिर login न करना पड़े; IP, time zone और language को एक साथ मेल कराया जाता है; और environments को computing resources की तरह ज़रूरत के अनुसार बनाया और वापस लिया जाता है।

PurpleMark इसी layer पर काम करता है। यह browser environments को schedulable resources में बदलता है, ताकि Agent task logic पर ध्यान दे सके।

इससे चयन को समझना भी आसान होता है। Enterprise testing stacks और मौजूदा script assets अपनी वर्तमान दिशा में रह सकते हैं; जिन complex Web applications को request-level control चाहिए, वे protocol-driven पीढ़ी के अनुकूल हैं; और model द्वारा plan किए गए tasks जिन्हें लंबे समय तक स्थिर चलना है, उनमें पहली दो पीढ़ियों की technologies अभी भी इस्तेमाल की जा सकती हैं, लेकिन environment layer को अलग से हल करना होगा। यदि आपके scenario में operation को ऐसा दिखना चाहिए जैसे कोई वास्तविक user कर रहा हो, तो यह ऐसी क्षमता नहीं है जिसे automation framework अकेले दे सके, चाहे पीढ़ी कोई भी हो।

तकनीकी रास्ते से बाहर एक और सीमा है: automated operations को target platform के नियमों और स्थानीय कानूनों का पालन करना चाहिए। किसी चीज़ का तकनीकी रूप से चलना यह साबित नहीं करता कि वह business के लिए भी उपयुक्त है।